Bryan Field-Elliot wrote:
> Sorry, my question was stated a little incorrectly... Both of the
> above tags are class-level tags after all. But I'm still confused
> over what the intended differences are?
>
> [...]
>
> I am experimenting with entity beans with a simple Integer primary
> key (no generated class).
Oops, I read "simpler" and assumed you had previously been using a
custom PK class. I'm hip-deep in refactoring a crazy tangle of
transactionally-varied SLSB code at the moment -- and I need a break, so
excuse me while I indulge in some light discussion. ;)
> The docs are unclear as to the difference between the "@ejb-bean
> primkey-field" tag (at the class level), and the "@ejb.pk" field (at
> the method level).
To briefly summarize the docs:
* @ejb.bean primkey-field (class)
"Defines the primary key field for the bean as per spec."
Note that it says *the* -- as in single -- primary key field.
Use this for a single-column PK typed as a java.lang object
which is
determined by the type of the field.
* @ejb.pk (class)
"Defines the primary key of an entity bean."
Use this group of tags to fully-control the PK class itself.
You must mark the read-accessor for each field in the PK with
the @ejb.pk-field tag.
* @ejb.pk-field (field read-accessor method)
This will denote the persistent field "X" as a primary key field,
which will be included in the generated primary key class."
> I was initially experimenting with @ejb.pk but it was generating
> Value Objects which didn't compile. I tried adding the class-level
> "@ejb-bean primkey-field", and now those compilation problems are
> gone. But I'm still left wondering what the real difference is
> between these tags, and when one vs. the other is appropriate?
If your PK is a single field of type java.lang.X, you can get away with
using the primkey-field tag at your option. Otherwise, whether you have
a multi-field PK, are using a custom PK class instead of java.lang.X,
or you're a control freak, you'll use the pk and pk-field tags together.
All my beans use java.lang.Integer as the PK, but I'll attempt a simple
multi-field example including the pertinent tags.
The Address EJB uses the owning User EJB's ID and its own type ("home",
"work", etc) as a combined PK instead of its own unique surrogate key.
Yes, it's contrived and I again would not recommend doing this unless
you *had* to, but here it is anyway.
package my.ejb;
/**
* @ejb.bean name="Address"
* @ejb.pk class="my.ejb.AddressPk"
* extends="my.ejb.BaseEntityPk"
*/
public abstract class AddressBean implements EntityBean
{
/**
* @ejb.pk-field
*/
public abstract Integer getUserId ( ) ;
public abstract void setUserId ( Integer userId ) ;
/**
* @ejb.pk-field
*/
public abstract String getType ( ) ;
public abstract void setType ( String type ) ;
}
Once this bean is processed (make sure to add the <entitypk/> subtask to
your <ejbdoclet> task), XDoclet will generate the AddressPk class
containing two fields with accessors, constructors, and basic toString,
hashCode and equals implementations.
So it looks like specifying @ejb.pk-field when you're using @ejb.bean
primkey-field is unnecessary, though if you switched to @ejb.pk you'd be
one step ahead.
Peace,
David Harkness
Sr. Software Engineer
Sony Pictures Digital Networks
(310) 482-4756
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
