At the bottom of the messages you will find the following:
========================================================================
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".
----- Original Message -----
From: Richard Pledereder <[EMAIL PROTECTED]>
Date: Thursday, March 1, 2001 6:55 pm
Subject: Re: Article on dependent objects
> On an aside ... any idea how I can get off the EJB-
> [EMAIL PROTECTED] list?!
>
> ----- Original Message -----
> From: "Evan Ireland" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 01, 2001 2:34 PM
> Subject: Re: Article on dependent objects
>
>
> >
> >
> > Dan OConnor wrote:
> > >
> > > Hi,
> > >
> > > Tyler Jewell, the BEA training director for Java and XML
> > > technologies, yesterday published an article called "What's Wrong
> > > with the EJB 2 Specification" at
> > > http://www.onjava.com/pu In this
> > > article, he identifies "dependent objects" as what is wrong
> with the
> > > EJB 2 specification.
> >
> > This makes very good reading and I recommend others to check it out.
> > I concur with Tyler's comments on the 'ejbRemove' issue, but
> > unfortunately this appears to be unfixable unless we force EJB users
> > to change their existing stateless session bean code.
> >
> > > I have seen indications that container managed persistence in the
> > > EJB 2.0 specification will be modified significantly from its
> > > Proposed Final Draft form (see, for example, several postings to
> > > this news group, or the comment in the release notes of the J2EE
> > > beta). I hope that any changes to this (IMHO) excellent
> > > specification will only make it even better. I am of course
> > > concerned that the opposite is possible, so I hope to begin a
> > > discussion based on Tyler's article. (I am not part of the Java
> > > Community Process and do not have access to any work
> > > subsequent to the proposed final draft.)
> >
> > In terms of dependent objects, I think that you will be pleasantly
> > surprised with the updated draft (and I hope we will be too when we
> > get to see it ourselves).
> >
> > I think it would be wise to "wait and see" and then have a
> discussion> on the next draft.
> >
> > > First, I would like to correct what I believe was a fairly basic
> > > technical mistake in Tyler's article. He says, "Dependent objects
> > > don't require primary keys." I would like to suggest that the
> > > opposite is the case, and I cite from 9.4.4.1 in the spec
> (proposed> > final draft): "The dependent object class instance
> must have a
> > > primary key value that is unique across all instances of the
> > > dependent object class."
> > >
> > > Second, I would like to talk about implementations of this spec.
> > > Tyler says: "Despite the number of vendors that have embraced the
> > > EJB 2.0 specification, I'm not aware of a single vendor that's
> > > implemented dependent objects, including BEA WebLogic and
> > > JBoss Server, which are usually the most updated
> > > implementations. It's likely that the confusion described here
> is felt
> > > by others in the industry too."
> > >
> > > It is not particularly surprising that there are no commercial
> > > implementations of a draft specification. Some vendors have
> > > expressed on this list a distaste for providing
> implementations of
> > > draft specifications as not being in the best interest of their
> > > customers, and I take them at their word. However, there are at
> > > least two vendors who have implemented dependent objects for
> > > preview to customers: Orion Application Server, and my company
> > > MVCSoft, which provides an "educational" version of an EJB 2.0
> > > persistence manager for (ironically) JBoss Server. I have
> personally> > implemented the majority of the specification, and I
> feel confident in
> > > saying that confusion would not defeat the engineers at any major
> > > application server vendor, including BEA.
> > >
> > > To be fair, Tyler may have meant that vendors have not
> > > implemented dependent objects because they did not feel the
> > > concept would survive to the final iteration of the
> specification. I can
> > > pretty much guarantee that the JBoss community did not feel this
> > > way at the time the EJB 2.0 proposed final draft was released.
> This> > is significant only because he cited JBoss in particular,
> along with
> > > his own company.
> > >
> > > Tyler has three specific objections to dependent objects. They
> are:> >
> > > (1) [Tyler:] "Dependent objects are meant to be all things to all
> > > people." [Dan:] Specifically he is referring to their dual use
> as local
> > > fine-grained objects and as objects that track the life-cycle
> of their
> > > parent. I honestly don't see why this dual use is bad, so I
> find it
> > > difficult to voice agreement or disagreement with this point.
> For that
> > > reason, I hope some list residents choose to respond to this point
> > > in particular (with clarifications, agreement, or disagreement).
> > >
> > > (2) [Tyler:] "Dependent objects have a cascading delete
> > > deployment descriptor option that instructs a container to manage
> > > the destruction of dependent objects attached to parent objects.
> > > This is needed to manage life cycle objects. The other
> > > characteristic needed to support life cycle objects, an automatic
> > > creation mechanism, does not exist, which makes the intentions of
> > > the specification developers murky." [Dan:] It seems to me that
> > > these two operations in the life-cycle of a dependent object
> are not
> > > symmetrical. The cascade-delete rule can often be specified free
> > > from context data (e.g. delete the line item whenever you
> delete the
> > > order) but creation almost always requires context data (how could
> > > you create the line items apart from application logic?) So I
> do not
> > > find this objection compelling.
> > >
> > > (3) [Tyler:] "Since dependent objects can only be accessed
> locally,> > home and remote interfaces are not necessary."
> [snip...] "The
> > > additional syntax that an EJB developer will have to learn will
> > > confuse new developers." [Dan:] I have two comments in response
> > > to this: [A] It seems to me that the inclusion of home and remote
> > > interfaces for local objects adds unnecessary complexity to the
> > > development process. Of course, most people will use tools to
> > > generate them, but still there are extra files to keep in
> synch; to
> > > worry about when debugging; to manage in your development
> > > environment; and to scan through when writing and maintaining
> > > code. Also, [B] it seems to me that providing home and remote
> > > interfaces for local objects implies the wrong semantics. Why
> > > provide remote interfaces for local objects? This is more
> likely to
> > > confuse developers than the simple semantics of a dependent
> > > object.
> > >
> > > I am a big fan of the EJB 2.0 specification's persistence model.
> > > However, there are definitely people with a different point of
> view.> > (See, for instance, the comments on this article at
> > > theserverside.com.) There's always room for improvement, and
> if a
> > > new version of the specification were to get rid of dependent
> > > objects (as Tyler suggests should happen) this could indeed be an
> > > improvement. However, I'm not convinced based on Tyler's
> > > arguments, and I would welcome comments on both sides of the
> > > issue.
> > >
> > > Thanks,
> > >
> > > Dan O'Connor
> > >
> > > P.S. Given the identity of Tyler's employer, I hope this doesn't
> > > count as a Weblogic-specific question.
> > >
> > >
>
========================================================================
===
> > > 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".>
> > --
> >
>
________________________________________________________________________
____
> ____
> >
> > Evan Ireland Sybase EAServer Engineering
> [EMAIL PROTECTED]
> > Wellington, New Zealand
> +64 4
> 934-5856
> >
> >
>
========================================================================
===
> > 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".
>
>
===========================================================================
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".
