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. On Tue, May 26, 2015 at 4:49 PM, Steve Ebersole <st...@hibernate.org> wrote: > 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 <st...@hibernate.org> > 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 <brme...@redhat.com> 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 <brme...@redhat.com> >>> 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" <st...@hibernate.org> >>> > > > To: "hibernate-dev" <hibernate-dev@lists.jboss.org> >>> > > > 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@lists.jboss.org >>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > > >>> > > >>> > >>> >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
