[webbeans-dev] Re: Removal of pluggability contracts

> Is there some rationale for why the context lifecycle management

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