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@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@gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org