It looks like I have to back away from my absolute position on this question.
After looking through the specs I find that the requirements for primary key
classes changed substantially between Moscone draft 2 and EJB 1.1 Public
Release. Here's the text:
Moscone Draft 2:
9.2.9 Enterprise Bean's primary key class
The Bean provider must specify a primary key class. The primary key type must
be either java.lang.String, or a class defined by the Bean Provider. The
primary key type is specified in the deployment descriptor. If the primary key
is a class defined by the Bean Provider, its definition must follow these
rules: � The primary key type must be public. � All fields in the primary key
class must be declared as public. � The class must have a public default
constructor. � The class must implement the hashCode() and equals(Object other)
methods to simplify the management of the primary keys by client code. � The
class must be serializable by the Java programming language Serialization
protocol.
EJB 1.1. Public Release:
9.2.9 Entity bean's primary key class
The Bean Provider must specify a primary key class in the deployment
descriptor. The primary key type must be a legal Value Type in RMI-IIOP. The
class must provide suitable implementation of the hashCode() and equals(Object
other) methods to simplify the management of the primary keys by client code.
So, as of EJB 1.1 Public Release, whether an Interface is valid as a Primary
Key class in a deployment descriptor depends on whether an interface can be a
legal Value Type in RMI-IIOP. I'm still trying to figure that one out.
We should probably decide what we need to do before we ship Fiji. I see two
possibilities:
1) Leave things as they are: you can use interfaces but you have to defeat
the validation.
2) Officially support interfaces and change the validation.
Bruce C.
Hasko Heinecke wrote:
> Hi everybody.
>
> In the latest release, GemStone's EJB server introduces improved deployment
> validation. In particular, an entity bean's primary key class "must be [...]
> not abstract". This collides with our requirement to use interfaces as
> primary key class. Of course, all classes that implement our primary key
> _interface_ do follow the rules, like implementing equals(), hashCode(), and
> being serializable. However, we need to specify an interface in the
> deployment descriptor.
>
> I guess, the restriction is derived from a somewhat unclear phrase in the
> EJB spec. Both EJB 1.0 and EJB 1.1 say something about primary key classes
> having to have a public default constructor. This is of course not possible
> in an interface.
>
> We can circumvent the restriction by
> setting -Dgsj.deployment.mildValidation=true in GemStone but we suspect it
> to be enforced in future releases.
>
> So what's the correct(TM) interpretation of the EJB spec concerning this
> issue? Are interfaces allowed as primary key classes, given that all
> implementing classes follow the rules?
>
> Regards,
>
> Hasko Heinecke
> Daedalos Consulting AG
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
