continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Tue, 23 Jan 2007 20:29:07 GMT
well, I believe a lot of the 'less then robust' stem from a couple of
things we ran into last summer doing some related work.  (at least for
me, others may vary)

I know joakim talked to erik some about the issues we ran into with
plexus-security at the time (now plexus-redback).

For those issues we implemented a role based access control model and
were trying to get it to play into jpox nicely but had nothing but
issues with a couple of different concepts, one being

Obj A has a List of Obj B's
Obj B can have a List of Obj B's
Obj C has a List of Obj B's

A change to one of these Object B's needed to be reflected in all
copies of it.  We tried a number of permutations of this to get it
working, ultimately reducing a lot of these Obj B references to id's
of Obj B's but even then we kept running into null pointers and
whatnot getting kicked out of jpox.  The objects were more complex
then just that, because were where multiple instances of this kind of
relationship on Obj A, but this was the crux of it.  I wish we had
kept some of those traces for you.  We were also trying to get indices
based on Strings working at the time and that was a source of issue as
well.  I am sure joakim followed up with a lot of these issues with
erik at the time we were getting this done trying to make sure we were
doing things right, but we were under a pretty tight timeline at the
time.  Joakim can speak a lot more directly to these issues.

Now we need to go back through and refactor the store because we had
chopped it down enough functionally just to get it working with jpox
at the time that we sacrificed some things we need to get back now.
Some of this jpox talk is rooted in those issues and poking around to
see if there is something else that might work a bit easier for us.
The desire being that we don't want to suffer through those trials and
tribulations again, it was very frustrating at the time.  Admittedly
it was a few versions back of jpox and we all know a lot more about it
then we did before.

My last experience with working with jpox was trying to get the
performance up to speed for continuum and plexus-security.  After
spending some time trying to get the ecache plugin working with we
ended up just putting caching into our store implementation and it
made a huge difference but its a maintenance annoyance and potential
for issue...and in a security system thats not good.  Joakim also
gathered some numbers on it when we were working on that and none of
the caching changes we made in jpox at the time amounted to a
performance increase, but when we used ecache directly the results
were dramatic.

Anyway, personally I am in favor of a review of the continuum store
api itself since I don't like how these jpoxism's seem expressed in
the api.  I understand the core issue is trying to reduce the amount
of data that needs to be pulled into objects by jpox for use in places
in continuum, but the current api is very clunky to work with...and if
we are going to review the continuum-store-api then its probably a
good idea to review the underlying implementation at the same time.

Andy, I know from the jpox forums and jira issues I have read that you
would much rather prefer my having given you hard and fast specific
implementation issues but this was all from last summer and I don't
have any of them at my immediate disposal.  For that I apologize...
but this history is primarily the source of my issues with jpox.
Perhaps the thing to do is to get back to the point these things were
expressing themselves with the newest version of jpox and bug you guys
more directly for assistance in resolving them.  Maybe joakim can come
up with specifics for you, I just don't have anything concrete in
front of me anymore.


On 1/23/07, Andy Jefferson <> wrote:
> >> JDO is not bad, but JPOX has proven to be less then robust.
> > Sometime ago I joined this list to provide an easier a communication channel
> > for solving continuum/jpox issues and besides a few emails no one has ever
> > requested any help on issues neither gave any feedback.
> > JPOX is the only implementation that passes JDO 2 TCK, and less than robust
> > argument does not sounds fair since you dont even ask for help.
> Only just saw this discussion and since it didn't seem to reach any conclusion
> I'll add my input :-)
> We (JPOX) have made ever effort to satisfy the needs of Continuum :-
> * I seem to remember making several fixes after emails from Jason and Trygve,
> for their specific mapping situations required by Continuum, and especially
> so they could meet their release deadlines.
> * Following those fixes I asked Jason to raise a JIRA issue for something that
> at a time I didn't have time to answer by email. I never saw a JIRA so have
> to assume that the issue was input data rather than anything in JPOX.
> * Erik has already asked (more than once) for input on *what* are the issues.
> * Any JIRA raised has always been either fixed or concluded (including 2
> recent ones specific to Postgresql).
> I see no outstanding JPOX JIRA issues of anything from any Continuum people.
> JPOX 1.1.6 is the latest production standard release. If you aren't using it
> then you should be.
> If phrases like "less than robust" are to be used, then please let's at least
> state what JPOX JIRA issues it is referring to, and show us the respect of
> mentioning it on the JPOX Forum so we have the opportunity to reply or
> provide what you need. I don't subscribe to this list
> Moving back to the original context of this thread, someone asked whether you
> ought to move to use JPA, use Java5 features etc. This is your decision, and
> i've no opinion/recommendation since you are the people
> developing/maintaining Continuum. I will say the following though :-
> JPOX 1.2 series :-
> * supports JDO 2.0 and JPA 1.0 persistence
> * supports JPA 1.0 annotations
> * supports JDO 2.1 annotations
> * is OSGi extensible
> The JPOX website has a comparison of JDO 2.0 and JPA 1.0. You should use
> comparisons like that for deciding what persistence API you should use.
> Needless to say that you could also go to forums like Spring and see the
> differences in behaviour between "compliant" implementations of the JPA
> standard and maybe consider what this says about the maturity of that
> standard in its 1.0 form.
> Thanks
> --
> Andy
> Java Persistent Objects - JPOX

jesse mcconnell

View raw message