[cdi-dev] [JBoss JIRA] (CDI-715) Transitive stereotype declarations - clarify conflicting default scopes

Martin Kouba (JIRA) issues at jboss.org
Mon Sep 4 08:48:01 EDT 2017


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

Martin Kouba updated CDI-715:
-----------------------------
    Description: 
Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined.
 
Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho).

Note that this is not a problem for {{@Named}}, {{@Alternative}} and -interceptor bindings-.
Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. -All bindings are added to the set-.

UPDATE: Interceptor bindings are probably also affected. The interceptors spec defines _"An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass."_ (3.3 Binding an Interceptor to a Component) which implies that multiple interceptor bindings of the same type are not supported. So the spec should probably cover cases where stereotypes declare the interceptor bindings of the same type.

  was:
Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined.
 
Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho).

Note that this is not a problem for {{@Named}}, {{@Alternative}} and interceptor bindings.
Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. All bindings are added to the set.



> Transitive stereotype declarations - clarify conflicting default scopes
> -----------------------------------------------------------------------
>
>                 Key: CDI-715
>                 URL: https://issues.jboss.org/browse/CDI-715
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Minor
>
> Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined.
>  
> Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho).
> Note that this is not a problem for {{@Named}}, {{@Alternative}} and -interceptor bindings-.
> Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. -All bindings are added to the set-.
> UPDATE: Interceptor bindings are probably also affected. The interceptors spec defines _"An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass."_ (3.3 Binding an Interceptor to a Component) which implies that multiple interceptor bindings of the same type are not supported. So the spec should probably cover cases where stereotypes declare the interceptor bindings of the same type.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


More information about the cdi-dev mailing list