[cdi-dev] [JBoss JIRA] Issue Comment Edited: (CDI-2) Interceptor bindings defined at method level should override those at the class level

[Marius Bogoevici (JIRA)]

    [ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603721#comment-12603721 ] 

Marius Bogoevici edited comment on CDI-2 at 5/23/11 1:43 PM:
-------------------------------------------------------------

Here is my suggestion on solving this:

1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion 

a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1.

b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes


2) Beans must observe the same rule as described by point 1 for class-level bindings.

3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands

4) Beans may define bindings at method level which override bindings at class level, were they inherited or explicitely defined.

      was (Author: marius.bogoevici):
    Here is my suggestion on solving this:

1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion 

a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1.

b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes


2) Beans must observe the same rule as described by point 1 for class-level bindings.

3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands

4) Beans may define bindings at method level which override bindings at class level, inherited or explicitely defined.
  
> Interceptor bindings defined at method level should override those at the class level
> -------------------------------------------------------------------------------------
>
>                 Key: CDI-2
>                 URL: https://issues.jboss.org/browse/CDI-2
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Interceptors
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Marius Bogoevici
>             Fix For: 1.1 (Proposed)
>
>
> Gavin said:
> "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec."
> In section 9.5.2 of the spec:
> If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira