I'm migrating an application which uses Spring DM & Virgo 3.05 to Gemini Blueprint & Virgo 3.6. I have it working but I would like to use Gemini DBAccess (with MySQL) and Gemini JPA.

Currently, my DB access is achieved with 3 of my OSGi bundles:

1. Datasource, providing a javax.sql.DataSource service (also uses a properties file to store DB connection params).
2. Domain model, which defines a persistence unit.
3. DAO, which consumes the datasource service and injects an EntityManager into various @Repository POJOs.

I've looked through all the Gemini JPA docs but I'm unclear how I should modify my bundle-context.xml. Previously I had this:

The PersistenceAnnotationBeanPostProcessor will make sure that the PersistenceContext is injected in your service and <tx:annotation-driven /> will make sure that all methods that are annotated with @Transactional will be executed within a transaction. Hope this helps.

Thanks for your reply, that makes sense. Are you using Gemini DBAccess/JPA? Also, what app server do you use?

So far, on Virgo 3.6 I'm seeing a strange problem when I deploy a simple Virgo plan with the required Gemini bundles and a test bundle with a persistence unit. Virgo goes into a loop, starting and stopping my plan hundreds of times:

Not sure what command line is in startup.sh, but you may want to put -DREFRESH_BUNDLES=FALSE where you invoke java. Set the Gemini debug flag (-DGEMINI_DEBUG=true) to let you see the tracing and you can ensure that the refresh is disabled (i.e. that the bundle is not refreshed).

Virgo tries to make the whole plan (application) atomic, so when Gemini JPA refreshes one bundle in the app Virgo will turn around and refresh the entire application. This gets things into an infinite loop and the badness you see is the result.

Yes, static weaving is your best best if you want to turn refreshing off and be confident that weaving is happening. The only other option is if you can control the way that things get resolved and guarantee that Gemini JPA can see the persistence bundles and register the weaving hooks before any of the entity classes get loaded by another bundle.

BTW, the reason why there is not much debugging info from Gemini JPA is because it barely gets a chance to start up and see its first bundle, which it looks like it refreshes, before it gets restarted, itself.

Mike, thanks again for your input and shedding some light on the cause. I'm not sure how I can control the bundle resolution (other than using a plan to control bundle start order) but I can live with static weaving if there's no other impact on disabling refresh.