Trying to get up to speed and provide feedback... <greetings all>
I'm not following the exact conversation here, so let me see if I can play it back. SFSBs have a lifecycle defined by the EJB spec. The WebBeans spec. makes reference to WebBeans remove methods (unique to WebBeans) that governed the lifecycle in a different way than the EJB @Remove method. The WebBeans spec. is now going to remove the WebBeans specific remove method. So far so good I think.
However, there were references to @Remove being for clients, not the container. That I'm having trouble with. Since the context is acting as a client to both create and destroy instances at appropriate times, shouldn't it drive the appropriate lifecycle methods? Also, there's a potential flaw in the EJB spec. that would prevent PreDestroy notification. The SFSB section states: "PreDestroy methods execute after any method annotated with the Remove annotation has completed.". Literally, a container could potentially not invoke PreDestroy if the @Remove method is not called at all.
Is there some rationale for why the context lifecycle management shouldn't drive the typical client lifecycle methods of the beans?
Thanks,
Jim Knutson
WebSphere J2EE Architect
Michael Keith <MICHAEL.KEITH@oracle.com>
Michael Keith <MICHAEL.KEITH@oracle.com>
12/22/2008 11:43 AM
|
|
Gavin,
Given that one of the primary characteristics of a context is its duration,
which may not line up exactly with the life cycle of the component itself,
one has to accept that there are going to need to be some extensions to the
life cycle of the component.
However, an extension to an existing life cycle is quite different from
defining an additional life cycle, which implies an additional component.
This is a somewhat separate discussion, though, that I won't get into now.
but that I think needs to be on the table at some point.
Anytime the life cycle of the context can make use of the existing life cycle
of the component then it is definitely an improvement, so this proposed change
is a good one, IMO.
> -----Original Message-----
> From: Gavin King [mailto:gavin@hibernate.org]
> Sent: Saturday, December 20, 2008 11:17 PM
> To: Java Community Process JSR #299 Expert List; Michael Keith; Jim
> Knutson; WebBeans
> Subject: Re: Removal of pluggability contracts
>
>
> On Sun, Dec 21, 2008 at 3:03 PM, Gavin King
> <gavin@hibernate.org> wrote:
>
> > SFSBs with no web bean remove method
> > ================================
> > We have an open issue w.r.t destruction of SFSBs which have no web
> > bean remove method. Now that the requirement for
> pluggability is gone,
> > I think we should simply say that in this case, the container must
> > destroy the SFSB when its context ends *without* calling any remove
> > method.
> >
> > I will go ahead and make that change unless there is someone who
> > objects to this.
>
> Alternatively, we could actually go further than this and simply
> eliminate the concept of the "Web Bean remove method" and the
> @Destructor annotation. @Remove methods are really intended to be
> called by clients, not by the container - and if you just want a
> callback, we already have @PreDestroy. I'm not sure that @Destructor
> is really adding any additional value.
>
> The more I think about this, the more I think this is the right way to
> go (and it simplifies the spec).
>
>
>
> --
> Gavin King
> gavin.king@gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>