The following issue has been updated:

    Updater: Ari Miller (mailto:[EMAIL PROTECTED])
       Date: Fri, 6 May 2005 4:24 PM
    Comment:
The change to the template should be visible by a simple diff to the attached 
file.  I changed a portion of the generated setAttribute method, specifically 
primaryKey.<XDtMethod:setterMethod/>(<XDtMethod:propertyName/>);
to
                <XDtEjbPk:ifIsPkField>
                // Set can be called in a constructor, before the primary key is
                // initialized
                if (primaryKey != null) {
                primaryKey.<XDtMethod:setterMethod/>(<XDtMethod:propertyName/>);
        }
                </XDtEjbPk:ifIsPkField>

    Changes:
             Attachment changed to valueobject.xdt
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1385?page=history

---------------------------------------------------------------------
View the issue:
  http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1385

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: XDT-1385
    Summary: valueobject.xdt logical flaw causes NullPointerException
       Type: Bug

     Status: Open
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: XDoclet
 Components: 
             EJB Module
   Versions:
             1.2.3

   Assignee: xdoclet-devel (Use for new issues)
   Reporter: Ari Miller

    Created: Fri, 6 May 2005 4:21 PM
    Updated: Fri, 6 May 2005 4:24 PM
Environment: Windows XP.  JDK 1.5.

Description:
A logical flaw in the version of valueobject.xdt included in release 1.2.3 
causes runtime NullPointerExceptions in the objects generated by that template. 
As of 1.2.3, the constructors call the appropriate set methods for individual 
attributes.  However, for any field that is part of the primary key, calling 
the setter method updates the primary key as well.  The primary key is not 
initialized until the end of the constructor, which means calling the 
constructor is guaranteed to throw a NullPointerException.

Below is an example of the generated code with this logical flaw:


public ModuleDTO( long id,com.portblue.model.creation.module.ModulePK 
key,java.lang.String name,boolean test,boolean global )
   {
       setId(id);
       setKey(key);
       setName(name);
       setTest(test);
       setGlobal(global);
       primaryKey = new 
com.portblue.model.creation.module.ModulePK(this.getId());
   }

   public void setId( long id )
   {
          this.id = id;
          idHasBeenSet = true;

      primaryKey.setId(id);
   }

Notice how setId attempts to set the id of a primary key object which isn't 
initialized at the time setId is called by the constructor.
I modified the valueobject.xdt template (modified version attached) to avoid 
this problem.
The setId method, after the modification, reads:

   public void setId( long id )
   {
          this.id = id;
          idHasBeenSet = true;

                // Set can be called in a constructor, before the primary key is
                // initialized
                if (primaryKey != null) {
                primaryKey.setId(id);
        }
   }


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
xdoclet-devel mailing list
xdoclet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel

Reply via email to