Oki, if I got this right then there might be 2 different things mixed up.
Q1: is it allowed to register an Alternative to a built-in Bean, e.g. an @Alternative for Provider?
Q2: what happens if you have an @Alternative Bean<X> but there is no enabled Bean<X>?
Btw, I think it is perfectly allowed to have an Alternative Bean without any original Bean.
{ noformat quote }
5.2.1. Unsatisfied and ambiguous dependencies
An unsatisfied dependency exists at an injection point when no bean is eligible for injection to the injection point. An ambiguous dependency exists at an injection point when multiple beans are eligible for injection to the injection point.
Note that an unsatisfied or ambiguous dependency cannot exist for a decorator delegate injection point, defined in Section 8.1.2, “Decorator delegate injection points”.
When an ambiguous dependency exists, the container attempts to resolve the ambiguity. The container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable.
{ noformat quote }
So from a pure spec perspective all the Alternative evaluation is ONLY done if there is an ambiguity in the first place! |
|
