OK, but, arguably this change is actually a change to the lifecycle of
SFSBs as defined by the EJB spec, since the EJB spec defines no way to
remove EJBs without the invocation of a @Remove method. The mechanism
defined the the early and public drafts of 299 was layered over this
lifecycle, by saying that one of these @Remove methods was "special"
and was called by the container.
However, it's become increasingly clear that there's no really "clean"
way to do this - in many cases it's difficult to identify which of the
remove methods is the "special" one without requiring additional
metadat. And, worse, I think it's a corruption of the semantics of
@Remove methods, which were designed to be called by the client, not
by the container.
And I don't think it's unprecedented to say that the container can
destroy an SFSB without invocation of a @Remove method, since it
already does that sometimes, for example when the @StatefulTimeout
occurs.
So, I would like to add this additional means of destruction - but not
before discussing it with Ken.
On Tue, Dec 23, 2008 at 4:43 AM, Michael Keith <MICHAEL.KEITH(a)oracle.com> wrote:
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(a)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(a)gmail.com
>
http://in.relation.to/Bloggers/Gavin
>
http://hibernate.org
>
http://seamframework.org
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org