[webbeans-dev] Interceptors (was Re: Creating instances of managed beans (including EJBs) in EE6 (was Re: non-contextual managed bean creation))
Pete Muir
pmuir at redhat.com
Sat Sep 5 03:02:06 EDT 2009
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
>>
>
More information about the weld-dev
mailing list