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

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 >