[webbeans-dev] Updated EJB SPI

[Pete Muir]

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

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). 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