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