[webbeans-dev] Re: Updated EJB SPI

[Kenneth Saks]

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/jboss/webbeans/ejb/spi/EjbServices.java 
>  - resolveEJB(EjbDescriptor<?> descriptor, NamingContext context);
> - http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jboss/webbeans/ejb/api/SessionObjectReference.java

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
>