[webbeans-dev] Re: Updated EJB SPI

On Mar 17, 2009, at 2:28 PM, Pete Muir wrote: > All, > > Based on coversations today with ALR and Ken, I've produced a > slightly updated SPI which is better aligned with the EJB > lifecycle. You can read the contracts here: > > - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... > - resolveEJB(EjbDescriptor<?> descriptor, NamingContext context); > - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... Hi Pete, What's the purpose of the NamingContext parameter on the resolveEJB() method? The EjbDescriptor object is provided by the ejb container so I would expect that to already encapsulate everything needed by the ejb container to resolve the EJB.

> > I'm still not convinced I have the terminology right here, so > please suggest changes to signatures as needed :-) > > Note that at the moment there is still a discussion about how the > SLSB and singleton lifecycle interacts with JSR299, so I've > concentrated on the SFSB case here - we'll go into more depth on > the SLSB/singleton case once we've clarified our understanding of > how JSR299 should behave. > > We also discussed in some detail the contract imposed by A2. > Session Bean Interceptor http://docs.jboss.org/webbeans/reference/snapshot/en-US/html/ri-spi.html > > ALR said that he would prefer us to register for lifecycle > callbacks from the EJB container programatically, rather than use > an EJB interceptor. > > I'll think about the API for this later today, but in essence we > would pass an extra object as part of the resolveEJB call above, > which would implement some callback interface in the Web Beans SPI > that allowed us to listen for at least postConstruct, > preInvokeBusinessMethod and preDestroy. The JBoss-Web Beans > integration project would then have to decorate this with an > interface JBoss EJB knows about, and somehow pass it to JBoss EJB3 > for registration. > > ALR, do you think we need to do this for the 1.0 of Web Beans, or > can address it for 1.1? I certainly agree that programmatic > registration of an interceptor is less brittle than the current > ThreadLocal approach, but if we can get away with the ThreadLocal > for now, it gives us more time work on a good SPI. > > BTW I think a good SPI would be to pass an EJB interceptor through > the resolveEJB method (which is a well known SPI). If we were to add explicit registration of the interceptor in the SPI it would be more appropriate to configure it at the bean-level at container initialization time rather than as part of the client's acquisition of a component reference at runtime. Doing it during resolveEJB might work in the contextual stateful session bean case but it doesn't work with non-contextual stateful session beans or stateless / singleton / message-driven beans.

--ken > Then e.g. Glassfish could register this as a system interceptor, > whilst JBoss EJB3 could adapt this to be lifecycle callbacks... > > Best, > > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete >