bob combs wrote:
> Problem lies in what's being generated in the getPrimaryKey()
> in the VO:
>
> public com.messagegate.foundation.id.UUID getPrimaryKey() {
> com.messagegate.foundation.id.UUID pk = new
> com.messagegate.foundation.id.UUID();
> return pk;
> }
WTF?! That's truly bizarre. What version of XDoclet are you using? I'm
on 1.2b2 and the template consists of
public <XDtEjbPk:pkClass/> getPrimaryKey()
{
return pk;
}
The constructors create the primary key when not provided, but when it
*is* provided, here's the tail of the constructor:
<XDtEjbPk:ifHasPrimkeyField>
pk = this.<XDtEjbPk:primkeyGetter/>();
</XDtEjbPk:ifHasPrimkeyField>
<XDtEjbPk:ifDoesntHavePrimkeyField>
pk = new <XDtEjbPk:pkClass/>(<XDtEjbPk:pkfieldListFrom
name="this"/>);
</XDtEjbPk:ifDoesntHavePrimkeyField>
Hmm, now that I look at it, it seems that if you use the class-level tag
(@ejb.primkey-field) it should be of the PK-class type, which is not the
case for custom PK classes AFAIK. Perhaps I'm mistaken and
@ejb.primkey-field can only be used when you aren't using a PK class. In
the case of a PK class you need to mark each field with @ejb.pk-field. I
could swear the docs say differently, but it's been a while.
In any case, you'll need to modify the template to modify how it handles
this issue. You really don't want to create a new PK every time you
access it. It should be created along with the VO and simply returned
directly.
> Any idea how to fix the getPrimaryKey issue, or is that a merge point
> solution too.
In this case it seems the template itself is incorrect, and so you can't
fix it with a merge point (you can't override a method in the same
class). You could add an abstract method in a common superclass for all
your VOs, but you'd still need to implement it to access the correct
field in the VO -- requiring a merge point or modifying the template.
You may as well just fix the template at that point to simplify your
life. :)
David Harkness
Sr. Software Engineer
Sony Pictures Digital Networks
(310) 482-4756
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
