[webbeans-dev] Interceptors (was Re: Creating instances of managed beans (including EJBs) in EE6 (was Re: non-contextual managed bean creation))
We now need to resurrect this discussion.
On 13 Aug 2009, at 20:31, Kenneth Saks wrote:
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.
Sure, this is a way of doing it.
We could
certainly have it registered so the class-name isn't hard-wired but
that's a separate issue.
Agreed.
Otherwise, it's complicated to represent the full set of
CDI-specific
interceptor metadata
such that it can be passed to the ejb container.
At JBoss we do intend to end up with a shared interceptor library
between Web Beans and EJB, so such a registry needs creating anyway.
Furthermore, even without this, we would probably want to build such a
registry internally, so it simply needs to be exposed.
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.
Why does it have to do this? Surely it could simply choose to take the
same implementation path as you suggest above of adding a single
interceptor which in turn delegates to the interceptor.
What's
the benefit of doing all this when
it's already known to the CDI impl?
I believe it is conceptually more correct, as the CDI spec clearly
talks about creating interceptor bindings not interceptors. The actual
interceptors are provided by Managed Beans or EJB. Now, Web Beans also
provides an implementation of Managed Beans as well as CDI, which does
blur the lines here, but we do not provide any EJB functionality, so I
believe it is more correct to provide the layer only for EJBs.
Finally, I do believe this approach will be easier for users to debug
when using EJBs, as they only have one type of interceptors to
understand.
>
> 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?
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev