]
Martin Kouba commented on CDI-437:
----------------------------------
For the record, Weld 3 currently tries to solve this problem in a way that if
{{AfterTypeDiscovery.getAlternatives().add()}} is used a "sythetic" priority is
assigned to the "list item". See also
{{org.jboss.weld.bootstrap.enablement.EnablementListView.getPriority(Item, Item)}} for
details.
The container cannot use the final value of
AfterTypeDiscovery.getAlternatives() properly
-----------------------------------------------------------------------------------------
Key: CDI-437
URL:
https://issues.jboss.org/browse/CDI-437
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.2.Final
Reporter: Martin Kouba
Priority: Minor
Labels: F2F2016
Fix For: 2.1 (Discussion)
{quote}
Any observer of this event is permitted to add classes to, or remove classes from, the
list of alternatives, list of interceptors or list of decorators. *The container must use
the final values of these collections*, after all observers of AfterTypeDiscovery have
been called, to determine the order of the enabled alternatives, interceptors, and
decorators for application. The initial values of these collections are defined by the
@Priority annotation.
{quote}
However, the container cannot use the final value of the alternatives collection
properly. The problem occurs if an extension adds an alternative class.
The container can either:
* use the index from the list -> selected alternatives with the same priority will not
cause {{AmbiguousResolutionException}} (this contradicts the spec), or
* use the original priority, an alternative added by an extension will be selected for an
application but without any priority value (this contradicts the spec) -> an extension
would not be able to affect the final ordering
The first option seems to be less harmful.