I meant in the failing Aries tests. Specifically I am wondering if somehow both bundles end up in org.hibernate.osgi.OsgiPersistenceProvider#osgiClassLoader.
I am not certain the scope of a org.hibernate.osgi.OsgiPersistenceProvider, but if it is created once then it sure seems dodgy to keep instance state related to bundles (org.hibernate.osgi.OsgiClassLoader#bundles) and their ClassLoaders (org.hibernate.osgi.OsgiClassLoader#classLoaders), let alone the caches of the loaded stuff (org.hibernate.osgi.OsgiClassLoader#classCache especially since that #classCache is keyed just by class-name.
This was a good instinct! Having stepped through the activation of the OSGiPersistenceProvider I see that the requesting bundle is not the persistence bundle, but in fact is org.apache.aries.jpa.container (The Aries JPA implementation). This means that only one org.hibernate.osgi.OsgiPersistenceProvider is ever created, and so the same OSGi ClassLoader is used all over the place! This bug hasn't shown up previously for two reasons:
- There aren't many OSGi tests that have clashing class names
- Hibernate is unusual in creating a per-bundle PersistenceProvider (although perfectly within its rights to do so).
This now looks to me like the Aries JPA container might be the component doing the wrong thing. I'll raise a bug there and see what can be done. |