I'm kind of curious of what would be the benefit of declaring them as
interfaces?
-----Original Message-----
From: May Charles N
[mailto:[EMAIL PROTECTED]
Sent: понеделник 30.6.2003 г. 16:02
To: [EMAIL PROTECTED]
Cc:
Subject:
cannot map CMP attributes of Interface types?
Correct me if I am
wrong… I cannot find a reason in the EJB 1.0, 1.1, or 2.0 spec
that CMP Entity attributes should NOT
be declared of Interface type. Certainly, the *runtime type* must be RMI-safe,
but must the *compile-time* type be
RMI-safe, according to spec?
For example,
consider:
public abstract class
ABean implements javax.ejb.EntityBean {
...context and lifecycle methods...
//this is a CMP, not a CMR attribute, declared
as an Interface type (java.util.List)
//it will be promoted to the remote
interface
public abstract
java.util.List getNonCMRAttribute();
public abstract void
setNonCMRAttribute(java.util.List
nonCMRAttribute);
}
This question arose
during a project migration from VisualAge for Java 4.0 to Websphere Studio
Application Developer 5.0.1.
The relevant mapping tools in VisualAge for Java and WebSphere
Application Developer
rely on user-developed “Custom Composer” classes, which convert between multiple database
columns and single EJB attributes.
Composers in VisualAge for Java 4.0 enable CMP
attributes to be of interface types like
this (albeit in EJB 1.0/1.1, not 2.0),
but Composers in WebSphere Studio Application Developer do
NOT allow CMP attributes of interface types. In WSAD, all CMP fields must be of concrete types.
Worse, the mapping tools work by introspecting the private field names of the
CMP attribut e
classes, rather than introspecting the public
getter/setter methods of the same
classes.
What I had declared in
VAJ were “virtual” fields in the Composer which the visual mapping
tools could map 1-for-1 to database columns, but the “virtual” fields did not correspond to field
names – or
even real attributes – in the composed object. What the Composer did was
just add all the virtual field values into an
ArrayList, in the same order every time.
So, my mapping is
broken and must be repaired. It’s easy enough to
work around, but what I can’t figure is why IBM
made WSAD more restrictive than VAJ. Which do you think is
true:
· The
new restriction is due to a section of the spec I just
haven’t found
· The new restriction is purely
arbitrary
· Having CMP attributes be of Interface
type is such
a poor design decision
that IBM decided to make it impossible to
do?
If the second, IBM
should re-enable the mapping behavior previously enabled. If the last, the
restriction should be in the spec.
Charles May
TDD/AFCO Systems
Group
Mellon Financial
Corporation
