[webbeans-dev] Re: Updated EJB SPI
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/jb...
- resolveEJB(EjbDescriptor<?> descriptor, NamingContext context);
-
http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb...
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