-
Notifications
You must be signed in to change notification settings - Fork 0
Proposal: OSGi
HHH-7527 (and sub-tasks) will address Hibernate ORM in OSGi environments.
OSGi-specific ORM branch
4.2 Pull Request
Example client bundles
- Enterprise OSGi. The OSGi container/runtime is in charge of aggregating all of the Bundles' persistence units into a single unit. That persistence unit is given to hibernate-entitymanager's BundleActivator. The container/runtime is also in charge of creating and managing the EntityManagerFactory.
- Users' Bundles create and manage their own JPA EntityManagerFactory, using packages exported by the hibernate-entitymanager Bundle.
- Users' Bundles create and manage their own SessionFactory, using packages exported by the hibernate-core Bundle. hibernate-entitymanager can be uninstalled entirely.
HHH-7527 will initially address #1. All ORM modules will have their own Bundle Manifests. In addition, hibernate-entitymanager will define a Bundle-Activator. The HibernateBundleActivator will provide HibernatePersistenceProvider as a "javax.persistence.provider" in the OSGi container. It will also be in charge of managing discovered Bundles' ClassLoaders, etc.
Eventually, we'd like to follow up by addressing #2 & #3. This may mean some of #1's functionality is pulled into hibernate-core or split up. Discussions are on-going.
In all other environments, Hibernate uses Jar scanning to find entities, mapping files, resources, etc. This currently does not work in an OSGi environment. At least within Karaf, the persistence unit's root URL uses the "bundle:/" protocol. Although a stream handler is provided in order to locate classes or resources, we cannot find a way to get a handle on the actual jar for scanning. This needs investigated further.
The HibernateBundleActivator registers itself as a BundleListener. ACTIVE Bundles need to be maintained for scanning and class loading. The prototype currently provides a custom ClassLoader that iterates through all ACTIVE Bundles until a class or resource is located, each time its requested. This is terrible for obvious reasons.
Instead, we're discussing alternatives and improvements:
- Request that users mark specific Bundles as "interesting to Hibernate". This could simply be an additional value in the manifest, an additional META-INF file, etc. Only Bundles housing mapping resources, entities, Services, Integrators, Types, UserTypes, etc. would be designated with the marking. Hibernate would then only need to maintain references to the Bundles it "cares" about.
- Cache references to all Classes and Resources discovered in all ACTIVE Bundles. This has obvious memory concerns, but would provide the best performance.
- Cache references to Classes and Resources as they are discovered for the first time. This also has memory and performance considerations.
We're also looking into auto-discovery of Hibernate extension points in Bundles: Services, Integrators, Types, UserTypes, etc. This presents numerous complications, so we're looking for help with use cases.
One specific question involves the Services. Should these be treated just like any other class in the Bundle? Or, should we also create an OSGi ServiceListener and have users register Services with the container?
Current examples require that client bundles be activated before Hibernate. At least within Karaf, when hibernate-entitymanagers's BundleActivator is started, the persistence unit is provided even though the client bundle hasn't completely started yet. If that happens, you'll get an "illegal bundle state" exception.
Is there a better way for the activator to watch for bundles with PUs prior to registering the persistence provider?
We need an effective way to permanently unit test as much of the capabilities as possible. Pax Exam was brought up as a possibility. Any others?
Although a few of us have past experience with OSGi environments, it would be extremely useful to know more about the community's use cases. If you have any relevant details, insights, feedback, or concerns, please join the discussion on HHH-7527 or its subtasks. Thanks!