But in the app-managed case isn't it always valid to assume that the ClassLoader of the bundle that makes up the PU (or "requesting bundle") is the correct one?

Also I think I see a general problem with how hibernate-osgi works. Correct me if I am wrong (please), but org.hibernate.osgi.HibernateBundleActivator is the BundleActivator for the hibernate-osgi bundle, yeah? As opposed to the "PU bundle". If so, it creates the ClassLoaderService to be used across all bundles that it provides persistence to. Which would be wrong, I believe. ClassLoaderService is meant to provide class-loading isolation/encapsulation for the Hibernate code for a given context. But the problem is that in an OSGi setting that context is really per requesting bundle. In concrete terms, at the moment the OsgiClassLoaderService is built once on the org.hibernate.osgi.HibernateBundleActivator#start and then stored on org.hibernate.osgi.HibernateBundleActivator as instance state. What I think should happen is that org.hibernate.osgi.OsgiSessionFactoryService and org.hibernate.osgi.OsgiPersistenceProviderService should each create the OsgiClassLoaderService per each call to their #getService calls.

Bram Pouwelse IIUC this would explain the cases you have seen where you said hibernate-osgi is holding on the the bundle ClassLoaders.