[webbeans-dev] Interceptors (was Re: Creating instances of managed beans (including EJBs) in EE6 (was Re: non-contextual managed bean creation))

[Pete Muir]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev