@brmeyer I see the purpose of this ClassLoader as being to provide a unified view of a given version of Hibernate in the OSGi framework (there could be several versions present). Once the Hibernate core, entitymanager and osgi bundles start exporting their packages with versions it will be possible to have multiple versions (e.g. 4.2.1 and 4.3.0-SNAPSHOT) running concurrently in the same framework. At this point the existing "flat classpath" approach of the previous OSGiClassLoader completely breaks.

The same thing also happens if you have multiple versions of the same persistence bundle in the framework. You can never tell which entity class you should be loading and are likely to load the wrong one.

What this class is doing now is identifying the bundles providing Session.class (which will be Hibernate core) and HibernatePersistence.class (which will be Hibernate entitymanager), to which the Hibernate osgi module was wired. It then creates a unified classloader view of these two bundles so that "The hibernate classes" can be loaded using a single classloader. Because we're delegating to the OSGi framework we know that we're going to get a consistent view (no horrible class visibility issues), and this classloader can then be passed to HibernatePersistence as "the classloader for loading internal classes".

As we discussed above, this one classloader isn't quite enough to solve all the TCCL visibility issues. This ClassLoader needs to be unified (on a per persistence unit basis) with the classloader that is returned by PersistenceUnitInfo#getClassLoader(). Having one ClassLoader instance per persistence unit will ensure that Hibernate can reliably see everything it needs to without breaking the modularity of the system