[webbeans-dev] Re: Updated EJB SPI

[Pete Muir]

On 17 Mar 2009, at 22:29, Carlo de Wolf wrote:

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

Yes, I agree - I have this JIRA issue for it - https://jira.jboss.org/jira/browse/WBINT-3 
  - this is also a general issue for any container that wishes to  
integrate WB I think.

I'll talk to Ales tomorrow and see how he thinks we should best expose  
this info from WB (which is not MC based).

> On another note I would name the SessionObjectReference.getReference  
> method getBusinessObject (in the likes of  
> SessionContext.getBusinessObject).

Done

> And both should throw an NoSuchEJBException if the EJB is already  
> removed.

Done

> (Note: keep the IllegalStateException for invalid businessInterface.)

Not IllegalArgumentException? I went for IllegalArguementException

I also did the changes Ken suggested whilst there...

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

Yes, this is what we are doing today I think (unless you mean  
something else?)

http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/microcontainer/src/main/java/org/jboss/webbeans/integration/microcontainer/deployer/metadata/WBEjbInterceptorMetadataDeployer.java

What do you think about my TODO - should we modify the ordering that  
someone puts in - I just don't know enough about JBoss metadata to  
know if this is safe or the best way to impl (I would just do it with  
decorators)/

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

Yes they can (of course, our system level interceptor can't ;-).

However, Ken (with his EJB RI lead hat on) and I (with JSR 299 RI lead  
hat on) agreed to leave JSR299 interceptors for now, as that part of  
JSR299 is still being actively worked on (possible merger into EJB  
spec) so I wasn't planning to open this can of worms yet.

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

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