Hi!
[EMAIL PROTECTED] wrote:
> I assume the bean developer in the ejbCreate implementation can rely on the
> bean's fields being set to Java language default values (0 for numerics, null
> for objects). This comes into play for fields that will not get set from an
> ejbCreate parameter (an example would be for attributes that are optional at
> create time but may be set later), so the programmer would naturally not set the
> field at all. Or if the desired initial value for a numeric field is always the
> same non-zero number, the natural Java programming style is to declare that
> value on the instance variable declaration, rather than coding a separate
> assignment statement to initialize it. I assume that supporting these standard
> initial value semantics is a responsibility of the container provider, even if
> the container is pooling and reusing entity bean instances.
See EJB1.1 Draft 3 s. 9.4.2, 2nd paragraph:
"The Container must ensure that the values of the container-managed
fields are set to the Java language
defaults (e.g. 0 for integer, null for pointers) prior to invoking an
ejbCreate(...) method on an
instance."
> I didn't see it stated in the spec, but I assume that entity bean
> implementations are allowed to implement additional methods, that are not
> defined on either the EntityBean interface or the entity's remote interface.
> These methods would not be visible to clients, but would be called from the
> implementations of the remote interface methods (they would just be an
> implementation detail).
Absolutely. One could also imagine a bean which implements two separate
interfaces and which can be exported many times with these different
interfaces.
> The spec and the Handle Javadoc don't specify anything about Handles support of
> equals. I would like to assume that the equals method for the Handles
> implementations would return true or false based on whether the Handles being
> compared represent the same entity (that is, give same result as calling
> isIdentical on the two entities, but without the overhead of using getEJBObject
> on each handle and then calling isIdentical), but I suspect that would not be a
> safe assumption since it is not explicitly defined that way in the spec. Any
> thoughts on that?
I wouldn't rely on it, no. In my view Handles have never been a good way
to deal with relationships, and with the new requirements in EJB1.1 on
container provider CMP implementations EJB's should never have to deal
with Handles at all IMHO. From EJB1.1 Draft 3 s. 9.4.1:
"The Container Provider may, but is not required to, use Java
Serialization to store the con-tainer-
managed fields in the database. If the container chooses a different
approach, the effect
should be equivalent to that of Java Serialization. The Container must
also be capable of per-sisting
references to enterprise beans� remote and home interfaces (for example,
by storing
their handle or primary key)."
This alone will remove alot of nasty code in current beans which deals
with entity bean reference management. Yiha...
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
