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

[Pete Muir]

Hi Ken,

Marius is working on a prototype for an interceptor registry next  
week, so I suggest we see the outcome of that, and how it fits into  
your API below.

Pete

On 2 Sep 2009, at 16:44, Kenneth Saks wrote:

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