[cdi-dev] [JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()

[Pete Muir (JIRA)]

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

Pete Muir commented on CDI-33:
------------------------------

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

Unfortunately, whilst I wish the spec read the other way, the consensus is that it reads the way Weld 1.1 is implemented. To quote the spec (as you mention above):

bq. The container must fire an event for each Java class or interface it discovers in a bean archive, before it reads the declared annotations.

bq. For each Java class or interface deployed in a bean archive, the container must: •	create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType,

With this in mind, reading the spec the only time the container must fire an event is when a class is deployed in a bean archive, it makes no mention of beans added in other ways. Assuming you have a typo above, and mean that the spec doesn't say that this is the only time the event should be fired, agreed, however Weld as the RI needs to promote portability, and making this event available outside of the spec required places would promote non-portability.

Agreed that the intent may have been the other way, but that did not get written down and we are stuck with what we have.

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

Agreed, with hindsight applied, it seems obvious that the spec should require it for both, however a spec is a spec and (especially by the RI) must be followed as written, and not as we guess the writers intended. So, unless there is a logical inconsistency between two paragraphs of the spec (which there are in a couple of places, in which we've gone with the stronger of the two) we need to follow the spec. There is no logical inconsistency between sections of the spec here, just between what many view as the correct way to do it, and the way the spec is written.

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

It is not the role of the RI to define or clarify the specification, but simply to provide a reference as to implementing the spec. I can put you in touch with folks at the JCP if you want to debate these points further, but this is how it is currently defined. I can't get around that :-(

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

I will look into this.

> 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