On Aug 13, 2009, at 3:11 PM, Pete Muir wrote:
I don't see why this approach prohibits that implementation.
In my proposal there is no notion of component-level or method-level
interceptors being passed in.
There isn't even a need to actually "register" something. It's as
simple as taking the existing
org.jboss.webbeans.ejb.SessionBeanInterceptor and just inserting it
later in the chain. We could
certainly have it registered so the class-name isn't hard-wired but
that's a separate issue.
Otherwise, it's complicated to represent the full set of CDI-specific
interceptor metadata
such that it can be passed to the ejb container. Then, the ejb
container has to process the underlying
interceptor classes for PostConstruct, AroundInvoke, etc, and meld
that with the component and
method-level lists in order to rebuild its interceptor chain. What's
the benefit of doing all this when
it's already known to the CDI impl?
Rather than using an internal API to transfer the needed
interceptors from the EnterpriseBean instance to the EJB
interceptor, we make this a public SPI, thus allowing an integrator
the flexibility to choose how to add these interceptors to the stack.
ALR, Carlo, any comment. Which do you guys prefer?