On Thu, 1 Mar 2001, Gene Chuang wrote:
> 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
Not quite. ejbCreate is always invoked at some point before a business
method is invoked - for stateless sessions, it is only called when an
instance is added to the pool.
> 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!
I don't think the ejbCreate callbacks are so bad: they're called when a
bean is created. What's probably confusing to people is the entity
lifecycle: just because there isn't an object instance in memory that is
identified as a particular entity doesn't mean that that entity doesn't
exists. The entity EJB lifecycle is similiar to the lifecycle of objects
in an ODMG compliant database - in the ODMG Java binding, constructors
were to be called only when a persistent object was actually created, not
when the object was merely fetched from the persistent store. I think this
is perfectly parallel with ejbCreate on an entity, and that is the actual
source of confusion.
I guess what all that says is that your entity initialization _does_ go
into ejbCreate, and it is called when the entity is created, quite
consistently and not sporadically: the problem is in how you define
'create' and 'initialization'.
>
> 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".
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
Opinions expressed are mine and do not neccessarily reflect any
position or opinion of nVISIA.
---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
-Eben Moglen
===========================================================================
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".
