[webbeans-dev] Re: Removal of pluggability contracts

[Gavin King]

> 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