I'm interested in whether others make the same interpretation or assumption
about the EJB spec on the following points.
The new deprecation of enterprise bean method implementations explicitly
throwing instances of RemoteException makes sense (since RemoteExceptions are
for system errors, not business logic errors), but I assume it is still allowed
(and not deprecated) for those methods to include RemoteException in their
method's throws clause as long as their implementations do not explicitly throw
new instances of RemoteException. The value of doing that is to avoid putting
an unnecessary and useless burden of exception handling on programmers whose
method implementations make method calls on EJB object remote interfaces. For
those cases where there is nothing constructive the bean developer would do if
RemoteException is thrown from such calls, the normal approach would be to not
catch RemoteException, and to just let it be implicitly propagated by including
RemoteException in the throws clause of your own methods.
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.
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).
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?
Erik Voldal
Email: [EMAIL PROTECTED]
Phone: 507-253-4788
===========================================================================
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".
