Hello.

I'm trying to set up a KAR packaging to deploy Hibernate 4.2.11 as a feature to our ServiceMix 4.5.

At this time, we exclude use newer version (4.3.5 for example) of hibernate that come with a JPA 2.1 level while our existing code is not really ready for.

My feature is almost ready, but I have still two problems. A copy of the feature at the end of the message.

The first is about the "hibernate-osgi" bundle that declares the following Import-Package : .

This import is obviously not resolved on Karaf.

The second problem is about the aries bundles that some examples of feature include in version 1.0.0, while our ServiceMix only provides a version 0.3.

When our bundle, with the PersistenceContext injection in the blueprint, is deployed, an error is thrown :



Some posts let understand that it may be a problem with old versions of aries JPA container.

I've been trying to add the aries 1.0.0 packages to my features, but they seem to be in conflict with the prepackaged versions of SerrviceMix.

An idea about this issues, or similar experiences ?

Thanks for your help.

Regards.

Hello, regarding the org.osgi.framework import, I'm confused when you say that "This import is obviously not resolved on Karaf". Most of our integration testing revolves around Felix, Karaf, and SMX, all of which should provide that package. Are you seeing otherwise? What's the exact error you receive?

Note that the features.xml file in our quickstarts is for reference only -- we definitely do not claim that they'll work in all versions of containers.

If I remember correctly, ServiceMix provides its own version of Aries, so including your own would probably introduce conflicts. It would be really interesting if you could modify, by hand, the Hibernate manifests and see if widening the version ranges would still work. I'm curious to see if the older version of Aries, etc. would still work. If they do, open a JIRA and ping me. I'll modify them to make sure it works.

Thanks!

Hello.

Sorry if I was not precise enough...

First about the OSGi environment : our ServiceMix in version 4.5.3 and its Karaf 2.2.11 provide an older version of the framework package (1.5.0), while the hibernate-osgi manifest requires :



An import for "wiring" is also set, but it seems that this version of Karaf comes with none.

Then, about Aries, as all my attempts to add an alternative packaging of several bundles finally only led to conflicts, I decided to let my tests on this version of ServiceMix for a moment, even if ultimately we'll have to come back latter since our customer's current platform relies on the older version, and evaluate the situation with a newer version (5.0.1), and come back to test the old Karaf only if I manage to execute controled versions of bith Hibernate and my own test bundles.

This late version of ServiceMix comes with several prepackaged Hibernate 3.3.2, 4.2.7 and 4.3.1. This Karaf also provide more recent version of Aries packages, among others, the JPA container comes in version 1.0.0 instead of the 0.3. Before anything, I've tested my bundles with the 4.2.7, as our code targets JPA 2.0 and all my JUnit tests are done with 4.2.12. But the same errors occured when the entity manager factrory is about to be created and injected in my DAO service.



I've found on the Karaf forum a post about same kind of errors, and an explanation about it (http://karaf.922171.n3.nabble.com/JPA-with-Karaf-td4031000.html). The problem seem to be in relation with the lifecycle of the bundles, something between the JPA continer, the Hibernate OSGi module and the DAO bundle itself.

A suggested workaround is to stop the Hibernate OSGi bundle, install our budles and restart Hiberanate's one. Changing the start level of the Hibernate OSGi module to make it start after all others is a possibility, and I've tested it with my own 4.2.12 feature.

This operation seems to work once, but any update of the DAO bundle leads the system to be instable, and a stop/start of the OSGi bundle is not always effective. Generally, rebooting ServiceMix reset the bundle start order and the entity manager after all is injected !

But transactions don't work, and write operations are not commited to the database. My service level bundle declares transactions requirement, but it seems that the entity manager is not actually managed and transactions are not propagated.



The DAO level bundle blueprint that exposes the persistence is the following :



Though, in my Hibernate feature, I activate the JPA and transaction features.

So, "bit by bit" I'm finally on a more optimistic perspective to find a solution, but it seems that anyway there is always a new concern...

Any idea about the transaction problem ?

Thanks for you help.

Regards.

Hello again.

I'm going on testing, and I've seen strange messages in the log files :



Do you think this may explain my transaction problem ?
What should be the problem ?

FYI, I only use non-JTA transactions, as expected in my persistence.xml :



Thanks for your help.
Regards.

Thanks much for all the info! Give me a few days -- we're swamped at the moment. But I'll definitely look into this. I'm sure some of the version ranges are too narrow, etc. -- most of what hibernate-osgi does is pretty basic stuff, so widening the ranges shouldn't be an issue.

Hello again !

I've continued my tests, and I've managed to build a set of bundles that work more or less as expected on our ServiceMix 5.0.1. Good news !

But, among the remaining problems, the most troublesome is the strange lifecycle issues. As described in other posts, After starting JPA and Hibernate features, it's mandatory stop the Hibernate OSGi bundle before deploying ours, and restart it afterward to make it take into account our persistence context.

Then, when we try to deploy new versions of our code, this Hibernate bundle seems to fails sometimes to get the new context.

Likewise, when restarting the server, despite the start levels of the bundles, the same Hibernate OSGi bundle fails three times out of four : it seems that sometimes the datasource that is created using a blueprint and exposed as a service is not fully available, and all the JPA chain is broken...

That offers an optimistic perspective from a developer point of view, but deployment operations and delivery in these conditions are still a true challenge.

Have you any idea to get a better mastering of all that ?

Thanks again.

Best regards.