[
https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys...
]
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