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

[Kenneth Saks]

On Aug 30, 2009, at 1:40 PM, Pete Muir wrote:

> We now need to resurrect this discussion.

Hi Pete,

I see your points.  Let's stick your original approach.   Here's a  
proposal for registerInterceptors.  If the
signature is too verbose we could instead define a data structure with  
getters for each piece of interceptor
metadata and pass that.

/**
*  Register the JCDI-specified interceptor information associated with  
a particular ejb.
*
* @param ejb  EjbDescriptor for the applicable ejb
*
* @param allInterceptors    Exhaustive set of all interceptors  
associated with this ejb via JCDI metadata.
* One instance of each will be created for each bean instance of the  
corresponding ejb.
*
* @param callbackInterceptorChain  Ordered list of JCDI-specified  
interceptor class names for interceptors that should be
* processed for callback methods.
*
* @param aroundInvokeInterceptorChains  Per-method Map of ordered  
lists of interceptor class names.  Each
* ordered list represents the JCDI-specified interceptor chain for a  
given method.   Every business method
* of the EJB must have an entry in this list.   An empty list value  
means there are no JCDI-specified
* AroundInvoke interceptors for that method.
*
* @param aroundTimeoutInterceptorChains  Per-method Map of ordered  
lists of interceptor class names.  Each
* ordered list represents the JCDI-specified interceptor chain for a  
given method.   Every business method
* of the EJB must have an entry in this list.   An empty list value  
means there are no JCDI-specified
* AroundTimeout interceptors for that method.
*/

registerInterceptors( EjbDescriptor ejb,
                                      Set<Interceptor> allInterceptors,
                                      List<String>  
callbackInterceptorChain,
                                      Map<Method, List<String>>  
aroundInvokeInterceptorChains,
                                      Map<Method, List<String>>  
aroundTimeoutInterceptorChains)



> 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
>