> 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
