Table of Contents
JPA
Aries JPA
Hibernate targets the OSGi 4.3 spec or later. It was necessary to start with 4.3, over 4.2, due to our dependency on OSGi’s BundleWiring for entity/mapping scanning [1].
Hibernate supports three types of configurations within OSGi.
Container-Managed JPA Container-Managed JPA
Unmanaged JPA Unmanaged JPA
Unmanaged Native Unmanaged Native
All three configurations have a QuickStart/Demo available in the https://github.com/hibernate/hibernate-demos
1. Container-Managed JPA
The Enterprise OSGi specification includes container-managed JPA. The container is responsible for discovering persistence units in bundles and automatically creating the EntityManagerFactory (one EntityManagerFactory per PersistenceUnit). It uses the JPA provider (hibernate-osgi) that has registered itself with the OSGi PersistenceProvider service.
1.1 Enterprise OSGi JPA Container
In order to utilize container-managed JPA, an Enterprise OSGi JPA container must be active in the runtime. In Karaf, this means Aries JPA, which is included out-of-the-box (simply activate the jpa and transaction features). Originally, we intended to include those dependencies within our own features.xml. However, after guidance from the Karaf and Aries teams, it was pulled out. This allows Hibernate OSGi to be portable and not be directly tied to Aries versions, instead having the user choose which to use.
That being said, the QuickStart/Demo projects include a sample features.xml showing which features need activated in Karaf in order to support this environment. As mentioned, use this purely as a reference!
2. Source
Hibernate
Datasource
I would simply deploy the blueprint xml by hand. Just treat it like a config file you would have to add. This is of course not everyone´s favorite style.
The problem with adding the blueprint to the feature is that it would have to be in the maven repo. As the username and password are in this file this is not recommended.
So another way to achieve what I did is separate the things that should be configured per server or stage from the things that keep the same like driver class name. You could use the config admin service in the blueprint file to move the username / password to a separate config file. This would make the whole thing a bit more complex though but you could then safely put the blueprint file into a feature.
https://github.com/hibernate/hibernate-demos/blob/master/hibernate-orm/osgi/managed-jpa/features.xml
Username/password/URL could be in <cm:properties/> and so handle in the “application” config oriented file in etc.
