<html><body>
<p><tt>Instead, could we provide an 80% success case and make the rest undefined?</tt><br>
<br>
<tt>I'd rather say, if the bean defines an @Remove method with the signature</tt><br>
<tt>void <method_name>(); then that method will be called at the end of the context.</tt><br>
<tt>If multiple @Remove methods exist that follow that pattern, the results</tt><br>
<tt>are undefined (i.e. containers may destroy the bean without calling any</tt><br>
<tt>or may call an arbitrary @Remove method). All exceptions thrown during </tt><br>
<tt>a call of the @Remove method are ignored, but should be logged.</tt><br>
<br>
<tt>This at least exercises typical component lifecycle behavior in the </tt><br>
<tt>typical cases. It also correlates (somewhat) with the way the JavaBeans</tt><br>
<tt>spec. expects JavaBeans components to be handled (i.e. method patterns).</tt><br>
<tt>In other words, when the container/runtime understands how to do something,</tt><br>
<tt>it should do it.</tt><br>
<tt><br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect</tt><br>
<br>
<tt>gavin.king@gmail.com wrote on 01/06/2009 06:04:15 PM:<br>
<br>
> > Is there some rationale for why the context lifecycle management shouldn't<br>
> > drive the typical client lifecycle methods of the beans?<br>
> <br>
> Jim, this is what we used to have, but it was causing all kinds of<br>
> problems. Basically, there is no good way to decide *which* remove<br>
> method the context should call to destroy the stateful bean. Stateful<br>
> beans can have an arbitrary set of remove methods and each of these<br>
> potentially has "special" semantics that go beyond simple destruction<br>
> of the bean. So there's no way for Web Beans to decide on its own<br>
> which one to call. Nor can we rely upon the user annotating the<br>
> "right" @Remove method, since we're supposed to be supporting<br>
> pre-existing EJBs with no special annotations. Nor can we require that<br>
> the user explicitly call the @Remove method before the context ends,<br>
> because any exceptions that occur during context destruction need to<br>
> be swallowed and logged - they occur too late in the request lifecycle<br>
> to do anything meaningful with them.<br>
> <br>
> So I think the best option is to say:<br>
> <br>
> If the application did not explicitly call a @Remove method before the<br>
> context ends, the container destroys the stateful bean w/o using any<br>
> @Remove method to do it. (The @PreDestroy callback would still occur.)<br>
> <br>
> I'm going to run this by Ken today.<br>
> <br>
> -- <br>
> Gavin King<br>
> gavin.king@gmail.com<br>
> <a href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a><br>
> <a href="http://hibernate.org">http://hibernate.org</a><br>
> <a href="http://seamframework.org">http://seamframework.org</a><br>
</tt></body></html>