MARK HAPNER wrote:
> Some elements of the EJB DD are dependent on its implementation.
I don't know what this means.
> Development and deployment tools will help keep these in sync.
This makes me nervous for future revisions of the specification. I have
no problem with something being broken out from code when changing it
does not fundamentally alter the semantics or behavior of the code. But
I do have a problem with having to rely on a/several specific tool(s) to
ensure that changes to one thing don't affect changes to the other. How
should one go about ensuring that no mistakes occur? What about when
things are checked into version control systems? What if the deployment
descriptor is branched/modified/hacked but its code is not?
> It was an
> explicit EJB design decision to limit EJB code to the minimum needed.
IMHO too much was put in the deployment descriptor.
> It would have been a bad design decision to use encoding in Java as a
> way to make deployment info 'read-only'. It is much clearer to keep code
> and deployment info clearly partitioned.
What about stateful and stateless session beans? The way a session bean
is conceived of, designed and coded is entirely dependent on whether
it's stateful or stateless. What benefit does putting the statefulness
flag in a descriptor have here? How is this a good example of
partitioning? Isn't statefulness something that should be encapsulated
by the bean itself and not by an external resource? What about issues
of keeping the two files (code/descriptor) in sync, since they must be
if the bean is to work properly?
Cheers,
Laird
===========================================================================
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".
