<html><body>
<p>Trying to get up to speed and provide feedback... <greetings all><br>
<br>
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. <br>
<br>
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.<br>
<br>
Is there some rationale for why the context lifecycle management shouldn't drive the typical client lifecycle methods of the beans?<br>
<br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect<br>
<img width="16" height="16" src="cid:1__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Michael Keith <MICHAEL.KEITH@oracle.com>">Michael Keith <MICHAEL.KEITH@oracle.com><br>
<br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td style="background-image:url(cid:2__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="40%">
<ul>
<ul>
<ul>
<ul><b><font size="2">Michael Keith <MICHAEL.KEITH@oracle.com></font></b><font size="2"> </font>
<p><font size="2">12/22/2008 11:43 AM</font></ul>
</ul>
</ul>
</ul>
</td><td width="60%">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">To</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">Gavin King <gavin@hibernate.org>, Java Community Process JSR #299 Expert List <JSR-299-EG@jcp.org>, Jim Knutson/Austin/IBM@IBMUS, WebBeans <webbeans-dev@lists.jboss.org></font></td></tr>
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">cc</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""><br>
</td></tr>
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">Subject</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">RE: Removal of pluggability contracts</font></td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="58"><img width="1" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""></td><td width="336"><img width="1" height="1" src="cid:3__=09BBFFA5DFEEAC648f9e8a93df938@us.ibm.com" border="0" alt=""></td></tr>
</table>
</td></tr>
</table>
<br>
<tt><br>
Gavin,<br>
<br>
Given that one of the primary characteristics of a context is its duration, <br>
which may not line up exactly with the life cycle of the component itself,<br>
one has to accept that there are going to need to be some extensions to the<br>
life cycle of the component. <br>
<br>
However, an extension to an existing life cycle is quite different from<br>
defining an additional life cycle, which implies an additional component. <br>
This is a somewhat separate discussion, though, that I won't get into now.<br>
but that I think needs to be on the table at some point.<br>
<br>
Anytime the life cycle of the context can make use of the existing life cycle <br>
of the component then it is definitely an improvement, so this proposed change<br>
is a good one, IMO.<br>
<br>
> -----Original Message-----<br>
> From: Gavin King [<a href="mailto:gavin@hibernate.org">mailto:gavin@hibernate.org</a>]<br>
> Sent: Saturday, December 20, 2008 11:17 PM<br>
> To: Java Community Process JSR #299 Expert List; Michael Keith; Jim<br>
> Knutson; WebBeans<br>
> Subject: Re: Removal of pluggability contracts<br>
> <br>
> <br>
> On Sun, Dec 21, 2008 at 3:03 PM, Gavin King <br>
> <gavin@hibernate.org> wrote:<br>
> <br>
> > SFSBs with no web bean remove method<br>
> > ================================<br>
> > We have an open issue w.r.t destruction of SFSBs which have no web<br>
> > bean remove method. Now that the requirement for <br>
> pluggability is gone,<br>
> > I think we should simply say that in this case, the container must<br>
> > destroy the SFSB when its context ends *without* calling any remove<br>
> > method.<br>
> ><br>
> > I will go ahead and make that change unless there is someone who<br>
> > objects to this.<br>
> <br>
> Alternatively, we could actually go further than this and simply<br>
> eliminate the concept of the "Web Bean remove method" and the<br>
> @Destructor annotation. @Remove methods are really intended to be<br>
> called by clients, not by the container - and if you just want a<br>
> callback, we already have @PreDestroy. I'm not sure that @Destructor<br>
> is really adding any additional value.<br>
> <br>
> The more I think about this, the more I think this is the right way to<br>
> go (and it simplifies the spec).<br>
> <br>
> <br>
> <br>
> -- <br>
> Gavin King<br>
> gavin.king@gmail.com<br>
> </tt><tt><a href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a></tt><tt><br>
> </tt><tt><a href="http://hibernate.org">http://hibernate.org</a></tt><tt><br>
> </tt><tt><a href="http://seamframework.org">http://seamframework.org</a></tt><tt><br>
><br>
</tt><br>
</body></html>