In the same vein with the ejbRemove issue is the inconsistent definition of
ejbCreate between session and entity beans.
EntityHome.create() is used to create a brand new row, while
SessionHome.create() is used to grab an available session bean.
SessionBean.ejbCreate() is ALWAYS invoked when a client wants a session
bean, but EntityBean.ejbCreate() is not; hence most beginner EJB developers
(I'll be the first to admit I fell into this trap ;-)) would put
initialization codes in both Session and Entity ejbCreate() and puzzle over
why initialization is done consistently on Sesison beans but sporatically on
Entity beans!
The solution to this would be to rename SessionHome.create() to
SessionHome.find() or something more apropo.
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
To: [EMAIL PROTECTED]
Sent: 3/1/01 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/pub/a/onjava/2001/02/28/ejb.html. 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".
