[cdi-dev] [JBoss JIRA] (CDI-291) Clarify interceptor/decorator resolution rules

[Pete Muir (JIRA)]

     [ https://issues.jboss.org/browse/CDI-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated CDI-291:
--------------------------

    Description: 
Currently the spec only says:

{quote}
 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.
{quote}

AND

{quote}
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.
{quote}

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.

  was:
Currently the spec only says:

{quote}
 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.
{quote}

AND

{quote}
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.
{quote}

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 X. 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.


    
> Clarify interceptor/decorator resolution rules
> ----------------------------------------------
>
>                 Key: CDI-291
>                 URL: https://issues.jboss.org/browse/CDI-291
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators, Interceptors
>    Affects Versions: 1.0
>            Reporter: Jozef Hartinger
>            Assignee: Pete Muir
>             Fix For: 1.1 (Proposed)
>
>
> Currently the spec only says:
> {quote}
>  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.
> {quote}
> AND
> {quote}
> 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.
> {quote}
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira