| Re: [science-iwg] A technical question : status of eclipselink / gemini JPA for usage in an extensible RCP application |
The first implementation of ICE's IPersistenceProvider service was JPA based and we used EclipseLink.
In my opinion, it was the worst way we could do persistence. Maybe we used it wrong, but it was slow, cumbersome, constantly breaking and we were genuinely lucky to get it both working and get the rest of ICE running in an OSGi environment. Almost nothing about it worked as written and most of the time the target platform wouldn't even resolve it correctly in development. That was about three years ago, so maybe it is all fixed now.
It was so bad in the end that I deleted it completely and took a week to reimplement our IPersistenceProvider service in XML using JAXB (and not the JAXB implementation from EclipseLink!). The result was a really sweet, robust system that almost never breaks. We've barely touched it in three years and it was ten times faster for our application. It is a poor man's database for sure, but we have no complaints.
So, I recommend you think about it long and hard and do many tests before committing to JPA and EclipseLink.
My apologies to Doug if this comes off as offensive. I'm sure EclipseLink works for some folks, it just didn't for us.
Jay
Adding Doug Clarke (EclipseLink Project Leader) to this, as he would be the guy who actually knows what's going on.
Doug - What is the state of EclipseLink being available as an OSGi bundle? (I think you'll have to subscribe to the list to reply)
On 04/02/2016 2:46 AM, Erwin de Ley wrote:
Dear all,
Triquetrum's goal is to be an open and extensible platform itself, but also to be able to deliver plugins that can easily be integrated in other such platforms.
And the typical shape will be an RCP application I guess.
(we'll also deliver headless components, but this is even irrelevant for the issue described)
At some point in the near future, we'll start integrating a persistence service, preferably based on JPA.
We will need to be able to provide & register entity implementations from our bundles, while also allowing other bundles to do the same.
And without blocking the possibility that they should belong to the same persistence unit.
(e.g. cases where extensions provide entity subclasses that must fit in one of the normal mapping strategies, or where there are associations mapped to foreign keys etc)
But there seem to be some issues with the current state-of-affairs to use a JPA implementation in an OSGi/RCP setup, in a modular way.
I.e. it is required that there is one-persistence-bundle-to-rule-them-all that registers all entities in one shot.
This of course does not fit our needs (as also for many other modular systems, for which OSGi is meant)
Furthermore it even seems that eclipselink, since some time, no longer targets an OSGi runtime, and that their support for this has been moved to Gemini JPA.
But Gemini JPA seems quite dead : a milestone that remains unfinished since a couple of years.
Does anyone have any experience in this? There are several old-and-more-recent forum posts and bugzilla tickets open in this domain, but there seems to be no evolution/solution in the 2 mentioned eclipse projects. Is there some effort/stretegy on some eclipse foundation PMC level or so, to determine what the strategy is related to JPA/OSGi/eclipse/modularity?
thanks
erwin
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
