Improve hibernate-osgi support in ORM 5

The OSGi documentation lists many caveats present when using hibernate-osgi in ORM 4.2 or 4.3. Many of them are due to architectural constraints within ORM, but several involve 3rd party containers/libraries.

This ticket will track subtasks that attempt to mitigate these caveats in ORM 5.

Technically, multiple persistence units are supported by Enterprise OSGi JPA and unmanaged Hibernate JPA use. However, we cannot currently support this in OSGi. In Hibernate 4, only one instance of the OSGi-specific ClassLoader is used per Hibernate bundle, mainly due to heavy use of static TCCL utilities. We hope to support one OSGi ClassLoader per persistence unit in Hibernate 5.

Some containers (ex: Aries) always return true for PersistenceUnitInfo#excludeUnlistedClasses, even if your persistence.xml explicitly has exclude-unlisted-classes set to false. They claim it's to protect JPA providers from having to implement scanning ("we handle it for you"), even though we still want to support it in many cases. The work around is to set hibernate.archive.autodetection to, for example, hbm,class. This tells hibernate to ignore the excludeUnlistedClasses value and scan for *.hbm.xml and entities regardless.

Scanning does not currently support annotated packages on package-info.java.

The environment should be considered STATIC. Hibernate currently does not support the ability to dynamically add and remove client bundles during runtime. Doing so is typically catastrophic. We hope to better support at least partially-dynamic environments in Hibernate 5.

In addition:

• Investigate whether or not Aries (and other containers) support scanning explicitly-listed jars