[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira