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