[cdi-dev] [JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
Aaron Anderson (JIRA)
jira-events at lists.jboss.org
Mon Mar 28 15:09:37 EDT 2011
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592223#comment-12592223 ]
Aaron Anderson commented on CDI-33:
-----------------------------------
Please consider the following:
1) Spec intent. Read in the context of the specification it is apparent that the ProcessAnnotatedType event is intended, as its name implies, to process all annotated types exposed to the container. No method on the event indicates that it is meant only for beans declared specifically in a bean archive but instead the methods act on the generic AnnotatedType interface. Additionally, while the spec says the container must fire the event for each bean discovered in the archive it does explicitly state that this is the only scenario the event may be fired in(if and only if). Even the Weld reference implementation made this intuitive assumption in Weld issue 486
2) Inconsistency of the veto method. Assume that the spec did intend for the event to only be triggered for auto discovered beans. When utilizing the bean discovery mechanism assemblers must be cognizant of each class included in the archive so that the dependency injection “auto wires” properly. The value of the veto method in this situation only seems limiting since in an assembled archive all types are assumed to have been already vetted by the assembler. Also, evaluate this scenario. An extension will malfunction if a given annotated type is exposed to the container so it must invoke the veto method to signal to the container to ignore the type. If the ProcessAnnotatedType event is not triggered for types added by another extension than it is entirely possible than another extension could introduce the problematic type and cause a conflict. Not allowing extensions interact with each other’s introduced types or forbidding the introduction of an extension to mediate between conflicting extensions will introduce irreconcilable extension conflicts.
3) Minimal impact of firing event. Given that for all other event types there is no differentiation between container discovered types and extension added types observers of the ProcessAnnotatedType event would not be impacted at all. The only scenario where a portability issue would arise is where an extension developer intuitively assumed the event would be fired for all annotated types . Given that Weld is the CDI RI it could set the standard for how the spec should be interpreted. I can’t imagine why another implementation would not follow suite with the more liberal interpretation of when the event should be fired given the limitations above.
4) Everyone is painfully familiar with the JCP process and the length of time it takes to approve a JSR and for it to be adopted. Please consider adding critical and simple clarifications like this to a JSR maintenance release rather than forcing us all to wait years for a CDI 1.1 release.
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the cdi-dev
mailing list