The original use of OsgiPersistenceProviderService/OsgiSessionFactoryService was unmanaged – application bundles requesting an EMF/SF on their own, with therefore limited "requestingBundle" scope. I now see that the Aries managed JPA path grabbing only a single OsgiPersistenceProvider, and the requestingBundle being the entire container, being extremely problematic.

Tim Ward, I'm leaning on you to decide the "correct" way of doing things, since Aries is our primary provider of managed JPA. I appreciate the fix of ARIES-1575. But, would we be better off in the long run with the fixes Steve suggested? Essentially, the variables in OsgiPersistenceProviderService would be moved to OsgiPersistenceProvider itself and created on-demand, one per EntityManagerFactory. Seems reasonable enough.

I can categorically state two things:

• What Hibernate is doing is absolutely acceptable within the OSGi spec, and is following a typical usage pattern for a Service Factory.
• Any OSGi/JPA code which uses its own bundle context rather than the bundle context of the persistence bundle to get a PersistenceProvider service is doing the wrong thing

Having done some background research I can also say that, sadly, all the OSGi/JPA code out there is doing the wrong thing. This includes the Aries JPA container (until the fix for Aries-1575), the OSGi JPA service RI, the Geronimo spec bundle, basically everything that I could find. I also note that the Hibernate provided JPA API doesn't provide OSGi integration at all.

I have already fixed the Aries JPA container, and I can do some work here to improve things in Aries JPA (e.g. providing a properly working JPA API bundle), but I don't have the ability to make changes to EclipseLink, or anywhere else that's doing this wrong.

There is also one further problem, which comes from the Persistence#getPersistenceUnitUtil() method. This has no scope for the persistence bundle, and so has to use a single PersistenceProvider for everything.

Even with with ARIES-1575, I'm wondering if other nasty CL-related side-effects could be hiding...

Having had another careful look at the Hibernate code, I'm pretty sure that it's safe. I'm also not sure that you want to move away from the Service Factory model because the public Hibernate docs talk about being able to use the PersistenceProvider service directly. I don't see how this will work with a singleton PersistenceProvider.

It should be noted that these problems don't affect other providers because they offer no native OSGi support, they rely on containers like Gemini JPA or Aries JPA for everything.

I think my views can be summarised as follows:

• Aries JPA should provide a working version of the JPA API. This should fix the bootstrap factory in OSGi when using Hibernate. Using the bootstrap factory is supported (although discouraged) by the OSGi JPA spec.
• Hibernate should probably not change anything in relation to this. The Hibernate code is following both the letter and the spirit of the OSGi core spec in providing its service. You shouldn't have to lose documented functionality because other libraries get it wrong.