[webbeans-dev] Re: Updated EJB SPI

[Carlo de Wolf]

I still haven't seen a design that can actually work in AS.
It all boils down the the MicroContainer integration. You can't resolve 
an EJB at any point in time, you can only resolve it using EjbServices 
interface after the EJBs are actually started. So first you must resolve 
your metadata to come up with a dependency item for the WB. This *must* 
be addressed.

On another note I would name the SessionObjectReference.getReference 
method getBusinessObject (in the likes of 
SessionContext.getBusinessObject). And both should throw an 
NoSuchEJBException if the EJB is already removed. (Note: keep the 
IllegalStateException for invalid businessInterface.)

I like the notion of a class interceptor (SessionBeanInterceptor) 
though, because it's a well defined interface which covers all needs. 
Except we need another notion than class interceptor to make sure it is 
registered in at the right time. So in effect we need to expose an 
interface that allows WB to bind an EJB interceptor in place. Hmm, this 
can be done in VDF with a SeamBeanInterceptorDeployer to modify the EJB 
metadata coming past.
I am wondering about other EJB interceptors though, can't they 
participate in WB? E.g. can I have bijection on EJB interceptors?
To me an EJB is a bean and interceptor instances.

Carlo

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