Details
Description
I created a hibernate adapter and tests and the following problem came out:
If there is not DataSourceFactory service for the necessary JDBC driver Hibernate will not work. The reason is that with many settings Hibernate wants to access the database during creating the EntityManagerFactory.
As much as I saw currently Aries works in the following way:
- A DelayedLookupDataSource is created for the PersistenceUnitInfo
- createContainerEntityManagerFactory is called. Here an exception may occur (Nullpointer if DataSourceFactory is used and Naming exception if service is polled via JNDI).
In my opinion it would be very useful if:
- Instead of DelayedLookupDataSource another DS is created which can check if the real DataSource is already available and it can access the database
- If datasource and database is available the createEntityManagerFactories function is called
It would be even better if:
- not createEntityManagerFactories but createEntityManagerFactory would be called which means that the different DataSources would be handled separately
As the best solution could be:
- Handling the JNDI urls that contain service references as well in the way that a service tracker is created and closes the EntityManagerFactory if the original DS is not available anymore. (if the OSGI spec could provide a new class like JNDIUrlServiceTracker than this solution could be done in a standard way. However no such class exist in the osgi spec yet (as much as I know)).
Steps to reproduce:
- Check out https://guest:guest@source.everit.biz:443/svn/everit-osgi/trunk
- Run "mvn clean install". As a result you will see that hibernate tests run from the hibernate/tests/core project
- Edit the hibernate/tests/core/pom.xml file: Take the biz.everit.osgi.jdbc.h2 dependency to the end of the dependency list
- Run the "mvn clean install" again. As now the DataSourceFactory will be available later than the aries.jpa.container is initialized the solution will not work
For a more detailed information about this kind of testing project hierarcy (with the possibility of debugging in eclipse) please see the tutorial at http://projects.everit.biz/everit-osgi/testing/step-by-step-guide.html
As much as I looked into the code of PersistenceBundleManager and related classes some refactor and code cleaning could be done (e.g. not calling always bundleStateChanged function and trying to find out inside that function why it was called...). If you are interested I could provide a patch within the next weeks how I imagine the code could be changed.