Uploaded image for project: 'CDI Specification Issues'
  1. CDI Specification Issues
  2. CDI-291

Clarify interceptor/decorator resolution rules


    • Icon: Clarification Clarification
    • Resolution: Obsolete
    • Icon: Major Major
    • TBD
    • 1.0
    • Decorators, Interceptors
    • None
    • Release Notes

      Currently the spec only says:

      A decorator is bound to a bean if:

      • The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu-
        tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points").
      • The decorator is enabled in the bean archive containing the bean.


      An interceptor is bound to a method if:

      • The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if
        it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which
        is not annotated @javax.enterprise.util.Nonbinding.
      • The interceptor intercepts the given kind of lifecycle callback or business method.
      • The interceptor is enabled in the bean archive containing the bean.

      What remains unspecified is:

      • In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application.
      • Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery.

            Unassigned Unassigned
            rhn-engineering-jharting Jozef Hartinger
            0 Vote for this issue
            4 Start watching this issue