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