AfterTypeDiscovery added alternative gets ineffective priority

When an Extension adds an alternative in AfterTypeDiscovery, the alternative gets assigned a priority by org.jboss.weld.bootstrap.enablement.EnablementListView#getPriority based upon the previous item in the alternatives list (it adds 10).

Note that it uses the previous one item only, so it assigns a priority greater than the currently last item, not greater than the priority of any other alternatives.

If prior to AfterTypeDiscovery the alternatives list already contains an alternative implementation of FooService with a priority (say 100), but it's not the last item in the alternatives list, then an Extension adds another alternative of FooService, that new alternative will get a priority 10 greater than the priority of the last alternative in the list, but not necessarily greater than 100, and therefore will not be chosen.

I believe the order of items in the list of alternatives should be used to choose the alternative implementation.

Perhaps the EnablementListView should consider the maximum priority of all entries in the alternatives list when added a new alternative. Perhaps that means a renumbering of priorities on all alternatives is necessary (for when someone goes Integer.MAX_VALUE).

I am happy to contribute a patch if I'm on the right track.

This may be related to CDI-437.