[webbeans-dev] Re: Updated EJB SPI
Kenneth Saks
Kenneth.Saks at Sun.COM
Tue Mar 17 15:00:55 EDT 2009
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.
>
> 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.
--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
>
More information about the weld-dev
mailing list