openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof <>
Subject ApplicationIdTool generated idclass and tokenizer inconsistency
Date Fri, 26 Feb 2010 14:51:33 GMT


While generating unit test for our code I decided to include auto-generated
Id classes for composite ids and had encountered bizzare inconsistency that
looks like a bug to me. Maybe there is a flaw in my understanding or this
functionality is not needed (I've had cache disabled so far, no
re-attachment) otherwise.

As far as I remember string representation of the Id class is used for
detach/attach cycle (cache too?)  and the string representation is created
by separating stringified values by "::".

for a case where:

class ClassA
 int x;
 int y;

class ClassB
 ClassA cA;
 int b;

fromstring of ClassBId passes only part of the string representation of
ClassA id to classA string constructor as nexttoken is not aware of the
composition of the ID and always extracts a single token:

CLassBId {
        private void fromString(String str) {
            Tokenizer toke = new Tokenizer(str);
            str = toke.nextToken();
            if ("null".equals(str))
                b = null;
                b = str;
            str = toke.nextToken();
            if ("null".equals(str))
                cA = null;
                cA = new classA.classAId(str);
so, obviously for classB with a string representation like 0::1::2 only "1"
is passed to the constructor using ClassA.toString which results in wrong
I have not been using detachement/attachment and have been wondering if this
inconsistency may have other impact during an object lifecycle.

The solution would be to pass full remaining part of the string and return
the last position for subsequent tokens extraction somehow.

Could you please confim this is a bug or a no-issue?
Best regards,

View this message in context:
Sent from the OpenJPA Users mailing list archive at

View raw message