[webbeans-dev] RE: Removal of pluggability contracts

Trying to get up to speed and provide feedback... <greetings all> I'm not following the exact conversation here, so let me see if I can play it back. SFSBs have a lifecycle defined by the EJB spec. The WebBeans spec. makes reference to WebBeans remove methods (unique to WebBeans) that governed the lifecycle in a different way than the EJB @Remove method. The WebBeans spec. is now going to remove the WebBeans specific remove method. So far so good I think. However, there were references to @Remove being for clients, not the container. That I'm having trouble with. Since the context is acting as a client to both create and destroy instances at appropriate times, shouldn't it drive the appropriate lifecycle methods? Also, there's a potential flaw in the EJB spec. that would prevent PreDestroy notification. The SFSB section states: "PreDestroy methods execute after any method annotated with the Remove annotation has completed.". Literally, a container could potentially not invoke PreDestroy if the @Remove method is not called at all. Is there some rationale for why the context lifecycle management shouldn't drive the typical client lifecycle methods of the beans? Thanks, Jim Knutson WebSphere J2EE Architect Michael Keith <MICHAEL.KEITH@or acle.com> To Gavin King <gavin(a)hibernate.org&gt;, 12/22/2008 11:43 Java Community Process JSR #299 AM Expert List <JSR-299-EG(a)jcp.org&gt;, Jim Knutson/Austin/IBM@IBMUS, WebBeans <webbeans-dev(a)lists.jboss.org&gt; cc Subject RE: Removal of pluggability contracts Gavin, Given that one of the primary characteristics of a context is its duration, which may not line up exactly with the life cycle of the component itself, one has to accept that there are going to need to be some extensions to the life cycle of the component. However, an extension to an existing life cycle is quite different from defining an additional life cycle, which implies an additional component. This is a somewhat separate discussion, though, that I won't get into now. but that I think needs to be on the table at some point. Anytime the life cycle of the context can make use of the existing life cycle of the component then it is definitely an improvement, so this proposed change is a good one, IMO.