-
Clarification
-
Resolution: Obsolete
-
Major
-
1.0
-
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.
AND
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.
- is related to
-
WELD-1073 Cannot enable interceptor that is not deployed in any bean archive
- Resolved