[webbeans-dev] Re: Updated EJB SPI

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

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