[cdi-dev] [JBoss JIRA] (CDI-200) ProcessBeanAttributes needs clarification

Pete Muir (JIRA) jira-events at lists.jboss.org
Wed Sep 5 11:56:32 EDT 2012


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

Pete Muir commented on CDI-200:
-------------------------------

(1) I don't think it was intended that it would.
(2) I don't think it was intended that it was.
(3) I think (a) is certainly right
(4) I think this probably needs to be checked during validation and treated as a deployment problems
(5) I think this probably needs to be checked during validation and treated as a deployment problems
                
> ProcessBeanAttributes needs clarification
> -----------------------------------------
>
>                 Key: CDI-200
>                 URL: https://issues.jboss.org/browse/CDI-200
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>    Affects Versions: 1.1.EDR
>            Reporter: Jozef Hartinger
>            Assignee: Pete Muir
>             Fix For: 1.1 (Proposed)
>
>
> The specification should clarify the following cases:
> (1) whether the ProcessBeanAttributes event should be fired for Beans registered using AfterBeanDiscovery.addBean() - if yes, it is necessary to clarify what would the value returned by PBA.getAnnotated() be.
> (2) whether the ProcessBeanAttributes event should be fired for built-in beans (my interpretation is that this is not required)
> (3) The attributes represented by a BeanAttributes object are not completely independent. It is necessary to clarify how the set BeanAttributes object is treated. I can see two options:
> (a) the container takes the final values of a BeanAttributes object and uses them
> (b) the container itself updates certain attributes to match CDI rules for example
> ** if an extension adds a @Named qualifier to the set of qualifiers, this change is automatically reflected within the name attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with @Named, the default name is implied and reflected within the name attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with @Alternative, this fact is reflected within the isAlternative attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with a scope annotation, this fact is reflected within the scope attribute
> In theory, conflicts may occur where for example an extension may set different values for the @Named qualifier and for the name attribute. With the latter approach, an extension loses part of the control. On the other hand, this approach may be more convenient.
> Another area that needs clarification is specialization. Suppose having beans A and B where B specializes A. According to the specification, the result of specialization should be visible at the time the ProcessBeanAttributes event is fired for B (the qualifiers and name of B are updated with values of A). The scenarios that need clarification are:
> (4) In the ProcessBeanAttributes phase, a qualifier is added to A (making B no longer a valid substite of A). Should the container detect this as a definition error or rather apply specialization (update the set of qualifiers of B) once again? The same applies for name. 
> (5) Similarly, the set of qualifiers of B may be reduced by an extension, causing the same problem.

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


More information about the cdi-dev mailing list