[hibernate-dev] hibernate-osgi JPA bootstrap & classloader

[Steve Ebersole]

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 <steve at 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 <steve at 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 <brmeyer at 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 <brmeyer at 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" <steve at hibernate.org>
>>> > > > To: "hibernate-dev" <hibernate-dev at 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 at lists.jboss.org
>>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>