[webbeans-dev] Re: Updated EJB SPI

[Pete Muir]

On 17 Mar 2009, at 19:00, Kenneth Saks wrote:

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

Yes, this is unecessary in the current design, and is just a left over  
from some older impl. I'll tidy this up tomorrow.

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

Ah yes - this is why I think going with the threadlocal hack is good  
for 1.0 as it leaves us time to get this (tricksy) SPI good.

Ok, I opened an issue for this for Web Beans 1.1 https://jira.jboss.org/jira/browse/WBRI-191

NB 1.1 doesn't relate to any spec numbering - it's just the next minor  
release of Web Beans after 1.0 - it's also my bucket for stuff that I  
really want to do, but isn't critical for the 1.0 release.

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

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete