[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [triquetrum-dev] [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
On Feb 4, 2016 5:59 AM, "Mike Milinkovich" <
mike.milinkovich@xxxxxxxxxxx> wrote:
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