> > > Is that the best way to know when TransactionManagers and DataSources
> > come
> > > and go too? Or is there a more specific concept for listening to an
> > "OSGi
> > > service"?
> >
> > At least for TransactionManagers, yes, the BundleListener is probably the
> > best approach. I'm not awa
More I mean what bundle(s) should I listen to in order to know that the
ClassLoader is no longer valid? Or how would I otherwise know that or be
notified of that?
I can ping Christian regarding Aries specifically and get his thoughts.
On Wed, May 27, 2015 at 9:16 PM, Brett Meyer wrote:
> > In
On Wed, May 27, 2015 at 9:09 PM, Brett Meyer wrote:
> > Is that the best way to know when TransactionManagers and DataSources
> come
> > and go too? Or is there a more specific concept for listening to an
> "OSGi
> > service"?
>
> At least for TransactionManagers, yes, the BundleListener is prob
> In regards to OsgiClassLoader and dynamically managing the "classpath", any
> thoughts on how to handle out single call to OsgiClassLoader#addClassLoader
> (from OsgiPersistenceProvider passing
> the javax.persistence.spi.PersistenceUnitInfo#getClassLoader we get from
> the e-OSGi container)?
>
> Is that the best way to know when TransactionManagers and DataSources come
> and go too? Or is there a more specific concept for listening to an "OSGi
> service"?
At least for TransactionManagers, yes, the BundleListener is probably the best
approach. I'm not aware of a more specific way beyo
rnatePersistenceProvider so that
>>> > > OsgiPersistenceProvider can give you the OsgiClassLoader to use.
>>> > >
>>> > > > Additionally, this ClassLoader is ultimately just used to build the
>>> > > > C
t;> > >
>> > > > Additionally, this ClassLoader is ultimately just used to build the
>> > > > ClassLoaderService which hibernate-osgi overrides anyway.
>> > >
>> > > Right, assuming you're talking about
>> > > 'Clas
way.
> > >
> > > Right, assuming you're talking about
> > > 'ClassLoaderHelper.overridenClassLoader'. But the intention there was
> to
> > > remove that whole class ASAP -- that was just a temporary hack for ORM
> 4,
> > > since CL
gt; remove that whole class ASAP -- that was just a temporary hack for ORM 4,
> > since CL handling was still really static. But admittedly, I'm a bit out
> > of touch with ORM 5, so I'm not sure if that's feasible yet.
> >
> > - Original Message -
> > &
M 4,
> since CL handling was still really static. But admittedly, I'm a bit out
> of touch with ORM 5, so I'm not sure if that's feasible yet.
>
> - Original Message -----
> > From: "Steve Ebersole"
> > To: "hibernate-dev"
> > S
Ebersole"
> To: "hibernate-dev"
> Sent: Saturday, May 23, 2015 1:49:50 PM
> Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
>
> Brett,
>
> As part of HHH-7527 (Enterprise OSGi support) you had changed
> the org.hibernate.jpa.boot.
Brett,
As part of HHH-7527 (Enterprise OSGi support) you had changed
the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
each method to additional accept a "providedClassLoader".
Every one of those methods however, also accepts
a org.hibernate.jpa.boot.spi.PersistenceUnitDescr
12 matches
Mail list logo
