Laird Nelson wrote:
>
> 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 was not a goal to keep the EJB and its DD info independent. While
some DD elements can be changed without affecting the implementation
others cannot. While that decision may be slightly unsettling it has
already proven to work well in practice. If there is any pressure, it is
to make more of the EJB definition declarative and less programmatic.
> > 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".
===========================================================================
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".
