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.

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.

On Wed, Jan 7, 2009 at 10:19 AM, Jim Knutson <knutson(a)us.ibm.com&gt; wrote: Sure. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

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(a)gmail.com wrote on 01/06/2009 06:04:15 PM: shouldn't

gavin.king(a)gmail.com wrote on 01/07/2009 07:25:17 PM: There's a similar problem on the @Init side as well. It appears you are specializing the init side to allow proper construction and initialization, but are now ignoring the destruction side of the equation. Also, the initialization side seems to force constructor based initialization. This would require the container to order instance construction and have pre-knowledge of instance initialization data. This implies that there cannot be loops in the graph of object relationships. My first preference is that all bean instance creation / destruction semantics be pushed to the EJB EG to deal with. My second preference is that bean construction / initialization be broken into 3 phases: 1) basic instance construction (i.e. JavaBeans null constructor / SFSB lookup) 2) dependency injection 3) business logic defined initialization Step one should be used for the same reasons that the JavaBeans spec. chose to use it. It frees tools / runtime to construct an instance without foreknowledge of specialized constructor behavior. Step two is separate because initializing state should be separate. from creating an instance. In this case, this is the container managed portion of initializing state. Step three allows known patterns for initializing a bean to take place. In this case, if there are known @Init methods that the runtime can understand how to call, it should call them. This separation allows for customization to occur as the concept of what a "bean" is expands. I would expect a similar correlation of steps in reverse order on the destroy side. 1) If there is a known @Remove method that the runtime can understand how to call, it should call it. 2) Container/runtime state notifications occur on the instance 3) Destruction / GC of the instance The gnarly things you are worried about in a @Remove method could just as easily occur in a @PreDestory method. There's nothing special about either other than transaction (in the EJB case). This brings up an important point. It may be necessary to perform. some DB operation at the end of the bean's life. @PreDestory runs under an unspecified tran and is explicity stated as not to be used for DB operations. If there's no @Remove invocation, then there's no way to perform the necessary DB update. I would say that if you're particularly worried about what happens. on invocation of @Remove, then add an editor note to the draft and solicit feedback. Thanks, Jim Knutson WebSphere J2EE Architect