[webbeans-dev] Re: Updated EJB SPI

[Pete Muir]

On 17 Mar 2009, at 19:22, Andrew Lee Rubinger wrote:

> Pete Muir wrote:
>> 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 raised this point to address a portable mechanism for JSR-299 to  
> integrate with EJB Implementations, where 299 is an add-on (consumer/ 
> client) atop EJB3.  If that's left out of scope as Ken suggests, any  
> vendor-specific way to get the job done should suffice. Especially  
> in the case of JBoss WebBeans, which is solving the problem without  
> touching the EJB3 codebase (==good).

Aha - yes, this is out of scope for JSR299, but I think it will be in  
scope for the next rev of the-spec-formely-know-as-Web-Beans and  
EJB... For now, we have to use vendor specific integration hooks  
between a JSR299 impl and EJB where the spec'd ones from EJB aren't  
suitable

>
>
>> 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.
>
> The current mechanism should be good for the time being.  My concern  
> is in imposing upon other vendors a specific implementation approach.

Ok - to that I would say two things:

* they are free to write their own 299 impl which does things in any  
way they like
* I'm quite happy to support alternative integration approaches if  
they use Web Beans (hence this discussion :-) - but as, atm, the  
servers that are interested in using Web Beans are JBoss and GlassFish  
my aim is to satisfy the requirements of these servers (i.e. you,  
Carlo, Ken).

> To that end, there are a few impositions the 299 spec defines that  
> are outside of the EJB spec, and I'll raise those points in a more  
> appropriate forum (the public webbeans-dev-list)
>
> * SFSB remove() bypassing business method @Remove
> * 299 injection inbetween backing object instance creation and  
> @PostConstruct (violating the client view)

I'll respond in detail when you send :-)

>
>
> S,
> ALR
>
> -- 
> Andrew Lee Rubinger
> Sr. Software Engineer
> JBoss, a division of Red Hat, Inc.
> http://exitcondition.alrubinger.com
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev

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