<html><body>
<p><tt>gavin.king@gmail.com wrote on 01/07/2009 07:25:17 PM:<br>
> So Jim this is kinda like what the spec used to say but now I just<br>
> think it's semantically wrong.<br>
> <br>
> There's nothing in the EJB spec to say that a remove method with no<br>
> parameters doesn't have strange side-effects, and in fact many<br>
> existing stateful beans do have remove methods with no parameters that<br>
> do more than simple cleanup.<br>
> <br>
> The basic problem is that the semantics of a remove method are *not*<br>
> that it is a container callback. There is already a container<br>
> callback: namely the @PreDestroy method. That's what should be called<br>
> when the context end. The @Remove method is meant to be called<br>
> explicitly by the client, and therefore can do all kinds of gnarly<br>
> things.<br>
</tt><br>
<tt>There's a similar problem on the @Init side as well. It appears you</tt><br>
<tt>are specializing the init side to allow proper construction and </tt><br>
<tt>initialization, but are now ignoring the destruction side of the </tt><br>
<tt>equation.</tt><br>
<br>
<tt>Also, the initialization side seems to force constructor based</tt><br>
<tt>initialization. This would require the container to order instance</tt><br>
<tt>construction and have pre-knowledge of instance initialization</tt><br>
<tt>data. This implies that there cannot be loops in the graph of</tt><br>
<tt>object relationships.</tt><br>
<br>
<tt>My first preference is that all bean instance creation / destruction</tt><br>
<tt>semantics be pushed to the EJB EG to deal with.</tt><br>
<br>
<tt>My second preference is that bean construction / initialization be</tt><br>
<tt>broken into 3 phases:</tt><br>
<br>
<tt>1) basic instance construction (i.e. JavaBeans null constructor / SFSB lookup)</tt><br>
<tt>2) dependency injection</tt><br>
<tt>3) business logic defined initialization</tt><br>
<br>
<tt>Step one should be used for the same reasons that the JavaBeans</tt><br>
<tt>spec. chose to use it. It frees tools / runtime to construct an</tt><br>
<tt>instance without foreknowledge of specialized constructor behavior.</tt><br>
<br>
<tt>Step two is separate because initializing state should be separate</tt><br>
<tt>from creating an instance. In this case, this is the container</tt><br>
<tt>managed portion of initializing state.</tt><br>
<br>
<tt>Step three allows known patterns for initializing a bean to take</tt><br>
<tt>place. In this case, if there are known @Init methods that the</tt><br>
<tt>runtime can understand how to call, it should call them.</tt><br>
<br>
<tt>This separation allows for customization to occur as the concept</tt><br>
<tt>of what a "bean" is expands.</tt><br>
<br>
<tt>I would expect a similar correlation of steps in reverse order</tt><br>
<tt>on the destroy side.</tt><br>
<br>
<tt>1) If there is a known @Remove method that the runtime can </tt><br>
<tt> understand how to call, it should call it.</tt><br>
<tt>2) Container/runtime state notifications occur on the instance</tt><br>
<tt>3) Destruction / GC of the instance</tt><br>
<br>
<tt>The gnarly things you are worried about in a @Remove method could</tt><br>
<tt>just as easily occur in a @PreDestory method. There's nothing</tt><br>
<tt>special about either other than transaction (in the EJB case).</tt><br>
<tt>This brings up an important point. It may be necessary to perform</tt><br>
<tt>some DB operation at the end of the bean's life. @PreDestory</tt><br>
<tt>runs under an unspecified tran and is explicity stated as not to</tt><br>
<tt>be used for DB operations. If there's no @Remove invocation, </tt><br>
<tt>then there's no way to perform the necessary DB update.</tt><br>
<br>
<tt>I would say that if you're particularly worried about what happens</tt><br>
<tt>on invocation of @Remove, then add an editor note to the draft</tt><br>
<tt>and solicit feedback.</tt><br>
<tt><br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect</tt><br>
<br>
</body></html>