We're updating the issue view to help you get more done. 

Improve hibernate-osgi support in ORM 5

Description

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

Environment

None

Status

Assignee

Brett Meyer

Reporter

Brett Meyer

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major