[webbeans-dev] Re: Removal of pluggability contracts

[Gavin King]

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.

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



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org