Eclipse Community Forums: Gemini » Gemini JPA messes around with OSGI startup sequence

Home » Eclipse Projects » Gemini » Gemini JPA messes around with OSGI startup sequence(Unable to get a good startup sequence with JPA)

Show: Today's Messages :: Show Polls :: Message Navigator

Gemini JPA messes around with OSGI startup sequence [message #1046763]

Mon, 22 April 2013 10:37

Kees Pieters

Messages: 24
Registered: July 2009

Junior Member

I have an RCP application that is configured with the following bundles:

-bundle RCP: is an Application that references services registered by bundle SERVICES. It holds dependencies to both SERVICES and PERSISTENCE
-bundle SERVICES: defines blueprint services and references a MANDATORY persistency service, bundle PERSISTENCE. It holds dependencies to PERSISTENCE.
-bundle PERSISTENCE: registers a gemini blueprint JPA service

Sometimes it works (which leads me to believe that the configurations in themselves are ok), but it seems very vulnerable to the applied startup sequence.

What I have found out is the following. Whenever I activate org.eclipse.gemini.jpa, it seems to do something with all the bundles in my runtime configuration. As a result, the RCP often can't startup (application id not found), which are caused by a number of exceptions:

java.lang.IllegalStateException: BundleContext is no longer valid

I THINK that the following happens:

- RCP starts up and begins to do it's thing
- org.eclipse.gemini.jpa starts up and interferes with the Application startup by stopping the relevant bundles, presumably SERVICES. A moment later SERVICES is restarted as DS takes over.

When the startup sequence is completed, and I run 'ss' in the console, everything seems fine (except for the afore mentioned exceptions). Obviously there are no startup problems when I do not activate org-eclipse.gemini.jpa (but with imaginable results...)

When I change the reference to the persistence service in SERVICES to optional, everything starts up without problems, but the services in bundle SERVICES will not have a connection to the database.

I am thinking of combining the SERVICES and PERSISTENCE bundles, which will reduce the number of steps between

RCP -> SERVICES ->PERSISTENCE -> Database (MySql)

but before doing so I would like advice from the community...I don't think the approach is that exotic, and there is still a vulnerability between the JPA startup and an RCP application startup.

Am I dealing with a JPA bug here, a runtime configuration issue, or is something else happening.

Thanks

Report message to a moderator

Re: Gemini JPA messes around with OSGI startup sequence [message #1046893 is a reply to message #1046763]

Mon, 22 April 2013 14:05

Kees Pieters

Messages: 24
Registered: July 2009

Junior Member

I have created a workaround / best practice that seems to work, by making the mutual dependencies less dense. What I doe is the following:

1: add a new bundle BUSINESS, that contains the interfaces that the three other bundles require
2: Decouple the dependency between RCP and SERVICES and make a new one to BUSINESS
3: Set auto-start of SERVICES to 'true'

so now the dependencies are:

RCP -> BUSINESS
SERVICES -> PERSISTENCE
-> BUSINESS

What happens is that RCP will start up independently from SERVICES / PERSISTENCE. At the same time SERVICES will start up and activate PERSISTENCE as well.
When the startup sequence has completed, the services can be referenced when needed. The only snag in this approach is when RCP has completed before SERVICES, and wants to populate a View. This could be managed (although I never like to do so) by the startup sequence.

I would appreciate suggestions on how to tackle these kinds of issues!

Thanks

[Updated on: Mon, 22 April 2013 14:45]

Report message to a moderator

Re: Gemini JPA messes around with OSGI startup sequence [message #1047009 is a reply to message #1046893]

Mon, 22 April 2013 17:09

Michael Keith

Messages: 243
Registered: July 2009

Senior Member

Hi Kees,

JPA is sensitive to startup issues because it needs to weave the persistent classes and if a class is already loaded then it can't do that. It tries to guarantee the weaving by doing a refresh on persistence unit bundles that are already loaded by the time Gemini JPA provider finds them, which means that any bundle that relies on the persistence unit bundles will also get refreshed. Unfortunately RCP seems to not do well if bundles get refreshed. What people tend to do is one or the other, or both, of the following:

- Turn off Gemini JPA refreshing (meaning that weaving of persistent entities may not occur)
- Control the startup sequence so that the bundles get loaded in an order that ensures that Gemini JPA will not have to refresh the bundles

I would recommend the latter, which I think is what you are currently doing.

-Mike

Report message to a moderator

Re: Gemini JPA messes around with OSGI startup sequence [message #1051922 is a reply to message #1047009]

Mon, 29 April 2013 11:26

Kees Pieters

Messages: 24
Registered: July 2009

Junior Member

Mike,

Thanks for the reply. Yes, the problem was introduced because I am currently engaged in a refactoring activity (to genmini blueprint), which created the dependency jumble. I have posted the my findings in

http://www.eclipse.org/forums/index.php/m/1051264/#msg_1051264

But As far as I can tell, the best ways to prevent these problems from occurring is to
- create a common bundle which holds all the interfaces and common classes
- decouple the persistence bundle (and dependent bundles) from the RCP
- make the connection between the persistence bundle and RCP through services, with (at best) dependencies with the common bundle
- Expect a situation that some services are not ready yet when the RCP views are started.

This refactoring approach seems to do the trick.

Report message to a moderator

Previous Topic:	Gemini DBAccess and Eclipse RCP
Next Topic:	Gemini Jpa: Howto specify a jpa vendor adapter?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Sep 18 11:19:44 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter