IIRC: OsgiPersistenceProvider and OsgiSessionFactoryService both need *some* way to build the OsgiClassLoader and pass it into Hibernate bootstrapping. For the SF, that's easy: just hand OSGiClassLoaderServiceImpl to BootstrapServiceRegistryBuilder. For EMF, it looks like I mistakenly overrode those Bootstrap methods -- I missed that PersistenceUnitDescriptor included the CL. So you're probably right -- presumably you could strip 'em out and somehow use the descriptor, but you might still need the overridden method in HibernatePersistenceProvider so that OsgiPersistenceProvider can give you the OsgiClassLoader to use. > Additionally, this ClassLoader is ultimately just used to build the > ClassLoaderService which hibernate-osgi overrides anyway. 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 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" <steve(a)hibernate.org&gt; > To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; > 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.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.PersistenceUnitDescriptor which exposes 2 > ClassLoader already. > > Additionally, this ClassLoader is ultimately just used to build the > ClassLoaderService which hibernate-osgi overrides anyway. > > Just curious if I missed something. Unless I did, it seems to me that we > really do not need these overloads on Bootstrap to support Enterprise > OSGi. This dove-tails with a discussion from the Karaf user list > ultimately discussing OsgiClassLoaderService and "holding bundles" that are > being re-installed or upgraded. Ultimately I am thinking through ways to > support being able to release OSGI bundle references from the > OsgiClassLoaderService... > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

> I would fully expect hibernate-osgi to not directly use Bootstrap to build > an EntityManagerFactoryBuilder. Bootstrap is geared toward users wanting > to leverage 2-phase JPA bootstrapping, not our components. I would have > expected Enterprise OSGi support to instead directly build (and possibly > override) EntityManagerFactoryBuilderImpl. I'll add that as a task for > post-5.0. +1, makes sense. I should have done that to begin with... > Because I think that is a first step in being able to better > manage bundles coming and going. Please correct me if I am wrong. At first glance, supporting bundles being activated/deactivated at runtime may just be limited to OsgiClassLoader and an impl of OSGi's "BundleListener". HibernateBundleActivator would simply register that listener during startup (BundleContext#addBundleListener), which would receive the events. As bundles are added/removed from the runtime, they'd just be added/removed from OsgiClassLoader#bundles. > Also I'd like to start making sure that we fully support (certain) OSGi services > being replaced. Especially thinking of TransactionManagers and DataSources. +1 > > > On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: > > > IIRC: > > > > OsgiPersistenceProvider and OsgiSessionFactoryService both need *some* way > > to build the OsgiClassLoader and pass it into Hibernate bootstrapping. For > > the SF, that's easy: just hand OSGiClassLoaderServiceImpl to > > BootstrapServiceRegistryBuilder. For EMF, it looks like I mistakenly > > overrode those Bootstrap methods -- I missed that PersistenceUnitDescriptor > > included the CL. So you're probably right -- presumably you could strip > > 'em out and somehow use the descriptor, but you might still need the > > overridden method in HibernatePersistenceProvider so that > > OsgiPersistenceProvider can give you the OsgiClassLoader to use. > > > > > Additionally, this ClassLoader is ultimately just used to build the > > > ClassLoaderService which hibernate-osgi overrides anyway. > > > > 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 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" <steve(a)hibernate.org&gt; > > > To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; > > > 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.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.PersistenceUnitDescriptor which exposes 2 > > > ClassLoader already. > > > > > > Additionally, this ClassLoader is ultimately just used to build the > > > ClassLoaderService which hibernate-osgi overrides anyway. > > > > > > Just curious if I missed something. Unless I did, it seems to me that we > > > really do not need these overloads on Bootstrap to support Enterprise > > > OSGi. This dove-tails with a discussion from the Karaf user list > > > ultimately discussing OsgiClassLoaderService and "holding bundles" that > > are > > > being re-installed or upgraded. Ultimately I am thinking through ways to > > > support being able to release OSGI bundle references from the > > > OsgiClassLoaderService... > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > >

I created the following 2 issues to track these improvements: https://hibernate.atlassian.net/browse/HHH-9818 https://hibernate.atlassian.net/browse/HHH-9819 On Tue, May 26, 2015 at 3:57 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Awesome, thanks! So I'll investigate BundleListener... > > 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"? > > Also, do the containers generally handle "in-flight" requests in regards > to TransactionManagers and DataSources on activated/deactivated? I > guess this is more a curiosity, since I do not see what we could do if the > container does not manage it. > > On Tue, May 26, 2015 at 3:26 PM, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: > >> > I would fully expect hibernate-osgi to not directly use Bootstrap to >> build >> > an EntityManagerFactoryBuilder. Bootstrap is geared toward users >> wanting >> > to leverage 2-phase JPA bootstrapping, not our components. I would >> have >> > expected Enterprise OSGi support to instead directly build (and >> possibly >> > override) EntityManagerFactoryBuilderImpl. I'll add that as a task for >> > post-5.0. >> >> +1, makes sense. I should have done that to begin with... >> >> > Because I think that is a first step in being able to better >> > manage bundles coming and going. Please correct me if I am wrong. >> >> At first glance, supporting bundles being activated/deactivated at >> runtime may just be limited to OsgiClassLoader and an impl of OSGi's >> "BundleListener". HibernateBundleActivator would simply register that >> listener during startup (BundleContext#addBundleListener), which would >> receive the events. As bundles are added/removed from the runtime, they'd >> just be added/removed from OsgiClassLoader#bundles. >> >> > Also I'd like to start making sure that we fully support (certain) >> OSGi services >> > being replaced. Especially thinking of TransactionManagers and >> DataSources. >> >> +1 >> >> > >> > >> > On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer(a)redhat.com&gt; >> wrote: >> > >> > > IIRC: >> > > >> > > OsgiPersistenceProvider and OsgiSessionFactoryService both need >> *some* way >> > > to build the OsgiClassLoader and pass it into Hibernate >> bootstrapping. For >> > > the SF, that's easy: just hand OSGiClassLoaderServiceImpl to >> > > BootstrapServiceRegistryBuilder. For EMF, it looks like I mistakenly >> > > overrode those Bootstrap methods -- I missed that >> PersistenceUnitDescriptor >> > > included the CL. So you're probably right -- presumably you could >> strip >> > > 'em out and somehow use the descriptor, but you might still need the >> > > overridden method in HibernatePersistenceProvider so that >> > > OsgiPersistenceProvider can give you the OsgiClassLoader to use. >> > > >> > > > Additionally, this ClassLoader is ultimately just used to build the >> > > > ClassLoaderService which hibernate-osgi overrides anyway. >> > > >> > > 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 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" <steve(a)hibernate.org&gt; >> > > > To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; >> > > > 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.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.PersistenceUnitDescriptor which >> exposes 2 >> > > > ClassLoader already. >> > > > >> > > > Additionally, this ClassLoader is ultimately just used to build the >> > > > ClassLoaderService which hibernate-osgi overrides anyway. >> > > > >> > > > Just curious if I missed something. Unless I did, it seems to me >> that we >> > > > really do not need these overloads on Bootstrap to support >> Enterprise >> > > > OSGi. This dove-tails with a discussion from the Karaf user list >> > > > ultimately discussing OsgiClassLoaderService and "holding bundles" >> that >> > > are >> > > > being re-installed or upgraded. Ultimately I am thinking through >> ways to >> > > > support being able to release OSGI bundle references from the >> > > > OsgiClassLoaderService... >> > > > _______________________________________________ >> > > > hibernate-dev mailing list >> > > > hibernate-dev(a)lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > >> > > >> > >> > >

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)? I am not sure what all makes up that ClassLoader.

> 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)? > > I am not sure what all makes up that ClassLoader. Another really good question, but not sure. I *hope* that Aries (and other Enterprise OSGi JPA providers) would smartly/narrowly scope that to the specific persistence unit and responsible bundle, but who knows what that actually means in practice. Since our Enterprise OSGi setup currently works, I would assume that *some* sort of scoping is in place. Otherwise, we'd hit CL conflicts.