Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <553342108.263291268647887164.JavaMail.jira@brutus.apache.org>
Date: Mon, 15 Mar 2010 10:11:27 +0000 (UTC)
From: "Krzysztof (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Created: (OPENJPA-1572) ApplicationIdTool generated ID
 classes do not cater for embedded composite IDs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

ApplicationIdTool generated ID classes do not cater for embedded composite IDs
------------------------------------------------------------------------------

                 Key: OPENJPA-1572
                 URL: https://issues.apache.org/jira/browse/OPENJPA-1572
             Project: OpenJPA
          Issue Type: Bug
          Components: tooling
    Affects Versions: 2.0.0-beta2
            Reporter: Krzysztof


Having ClassB identified by the composite identity of the classA which has a 'simple types' composite identity, i.e.:

class ClassA 
{ 
 @Id 
 int x; 
 @Id 
 int y; 

} 
class ClassB 
{ 
 @Id 
 ClassA cA; 
 @Id 
 int b; 
} 

Generated ClassBId.fromstring  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 which will result in the null exception.

CLassBId { 
... 
        private void fromString(String str) { 
            Tokenizer toke = new Tokenizer(str); 
            str = toke.nextToken(); 
            if ("null".equals(str)) 
                b = null; 
            else 
                b = str; 
            str = toke.nextToken(); 
            if ("null".equals(str)) 
                cA = null; 
            else 
                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 initialization. 
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. 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.