By default, a bean archive has no selected alternatives. An alternative must be explicitly declared using the <alternatives> element of the beans.xml file of the bean archive. The <alternatives> element contains a list of bean classes and stereotypes. An alternative is selected for the bean archive if either:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
   <alternatives>
      <class>org.mycompany.myfwk.InMemoryDatabase</class>
      <stereotype>org.mycompany.myfwk.Mock</stereotype>
      <stereotype>org.mycompany.site.Australian</stereotype>
   </alternatives>
</beans>

Each child <class> element must specify the name of an alternative bean class. If there is no class with the specified name, or if the class with the specified name is not an alternative bean class, the container automatically detects the problem and treats it as a deployment problem.

Each child <stereotype> element must specify the name of an @Alternative stereotype annotation. If there is no annotation with the specified name, or the annotation is not an @Alternative stereotype, the container automatically detects the problem and treats it as a deployment problem.

If the same type is listed twice under the <alternatives> element, the container automatically detects the problem and treats it as a deployment problem.

For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls isAlternative() to determine whether the bean is an alternative, and getBeanClass() and getStereotypes() to determine whether an alternative is selected in a certain bean archive.

A bean is said to be enabled if:

Otherwise, the bean is said to be disabled.

Note that Section 3.12, “@New qualified beans” defines a special rule that determines whether a @New qualified bean is enabled or disabled. This rule applies as only to @New qualified beans, as an exception to the normal rule defined here.

Suppose an enabled bean X specializes a second bean Y. If there is another enabled bean that specializes Y we say that inconsistent specialization exists. The container automatically detects inconsistent specialization and treats it as a deployment problem.

A bean is available for injection in a certain module if:

For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls getBeanClass() to determine the bean class of the bean and InjectionPoint.getMember() and then Member.getDeclaringClass() to determine the class that declares an injection point.

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.

The container must validate all injection points of all enabled beans and of all other Java EE component classes supporting injection when the application is initialized to ensure that there are no unsatisfied or unresolvable ambiguous dependencies. If an unsatisfied or unresolvable ambiguous dependency exists, the container automatically detects the problem and treats it as a deployment problem.

For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls getInjectionPoints() to determine the set of injection points.

Any legal bean type, as defined in Section 2.2.1, “Legal bean types” may be the required type of an injection point. Furthermore, the required type of an injection point may contain a wildcard type parameter. However, a type variable is not a legal injection point type.

If an injection point type is a type variable, the container automatically detects the problem and treats it as a definition error.

A parameterized bean type is considered assignable to a raw required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.

A parameterized bean type is considered assignable to a parameterized required type if they have identical raw type and for each parameter:

For example, Dao is eligible for injection to any injection point of type @Default Dao<Order>, @Default Dao<User>, @Default Dao<?>, @Default Dao<? extends Persistent> or @Default Dao<X extends Persistent> where X is a type variable.

public class Dao<T extends Persistent> { ... }

Furthermore, UserDao is eligible for injection to any injection point of type @Default Dao<User>, @Default Dao<?>, @Default Dao<? extends Persistent> or @Default Dao<? extends User>.

public class UserDao extends Dao<User> { ... }

Note that a special set of rules, defined in Section 8.3.1, “Assignability of raw and parameterized types for delegate injection points”, apply if and only if the injection point is a decorator delegate injection point.

For the purposes of typesafe resolution and dependency injection, primitive types and their corresponding wrapper types in the package java.lang are considered identical and assignable. If necessary, the container performs boxing or unboxing when it injects a value to a field or parameter of primitive or wrapper type.

However, if an injection point of primitive type resolves to a bean that may have null values, such as a producer method with a non-primitive return type or a producer field with a non-primitive type, the container automatically detects the problem and treats it as a deployment problem.

For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls isNullable() to determine whether the bean may have null values.

Qualifier types may have annotation members.

@PayBy(CHEQUE) class ChequePaymentProcessor implements PaymentProcessor { ... }

@PayBy(CREDIT_CARD) class CreditCardPaymentProcessor implements PaymentProcessor { ... }

Then only ChequePaymentProcessor is a candidate for injection to the following attribute:

@Inject @PayBy(CHEQUE) PaymentProcessor paymentProcessor;

On the other hand, only CreditCardPaymentProcessor is a candidate for injection to this attribute:

@Inject @PayBy(CREDIT_CARD) PaymentProcessor paymentProcessor;

The container calls the equals() method of the annotation member value to compare values.

An annotation member may be excluded from consideration using the @Nonbinding annotation.

@Qualifier
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface PayBy {
    PaymentMethod value();
    @Nonbinding String comment() default "";
}

Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application. If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior results.

A bean class or producer method or field may declare multiple qualifiers.

@Synchronous @PayBy(CHEQUE) class ChequePaymentProcessor implements PaymentProcessor { ... }

Then ChequePaymentProcessor would be considered a candidate for injection into any of the following attributes:

@Inject @PayBy(CHEQUE) PaymentProcessor paymentProcessor;

@Inject @Synchronous PaymentProcessor paymentProcessor;

@Inject @Synchronous @PayBy(CHEQUE) PaymentProcessor paymentProcessor;

A bean must declare all of the qualifiers that are specified at the injection point to be considered a candidate for injection.

An ambiguous EL name exists in an EL expression when an EL name resolves to multiple beans. When an ambiguous EL name exists, the container attempts to resolve the ambiguity. The container eliminates all 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 EL name is called resolvable.

All unresolvable ambiguous EL names are detected by the container when the application is initialized. Suppose two beans are both available for injection in a certain war, and either:

the container automatically detects the problem and treats it as a deployment problem.

Certain legal bean types cannot be proxied by the container:

If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem.

Every time a method of the bean is invoked upon a client proxy, the client proxy must:

If the scope is not active, as specified in Section 6.5.1, “The active context object for a scope”, the client proxy rethrows the ContextNotActiveException or IllegalStateException.

The behavior of all methods declared by java.lang.Object, except for toString(), is undefined for a client proxy. Portable applications should not invoke any method declared by java.lang.Object, except for toString(), on a client proxy.

When the container instantiates a managed bean or session bean with a constructor annotated @Inject, the container calls this constructor, passing an injectable reference to each parameter. If there is no constructor annotated @Inject, the container calls the constructor with no parameters.

When the container creates a new instance of a managed bean, session bean, or of any other Java EE component class supporting injection, the container must:

The container must ensure that:

When the container destroys an instance of a bean or of any Java EE component class supporting injection, the container destroys all dependent objects, as defined in Section 6.4.2, “Destruction of objects with scope @Dependent”, after the @PreDestroy callback completes and after the servlet destroy() method is called.

When the container calls a producer or disposer method, the behavior depends upon whether the method is static or non-static:

The container passes an injectable reference to each injected method parameter. The container is also responsible for destroying dependent objects created during this invocation, as defined in Section 6.4.2, “Destruction of objects with scope @Dependent”.

When the container accesses the value of a producer field, the value depends upon whether the field is static or non-static:

When the container calls an observer method (defined in Section 10.4, “Observer methods”), the behavior depends upon whether the method is static or non-static:

The container must pass the event object to the event parameter and an injectable instance to each injected method parameter. The container is also responsible for destroying dependent objects created during this invocation, as defined in Section 6.4.2, “Destruction of objects with scope @Dependent”.

The interface javax.enterprise.inject.spi.InjectionPoint provides access to metadata about an injection point. An instance of InjectionPoint may represent an injected field or a parameter of a bean constructor, initializer method, producer method, disposer method or observer method.

public interface InjectionPoint {
    public Type getType();
    public Set<Annotation> getQualifiers();
    public Bean<?> getBean();
    public Member getMember();
    public Annotated getAnnotated();
    public boolean isDelegate();
    public boolean isTransient();
}

Occasionally, a component with scope @Dependent needs to access metadata relating to the object into which it is injected. For example, the following producer method creates injectable Loggers. The log category of a Logger depends upon the class of the object into which it is injected:

@Produces Logger createLogger(InjectionPoint injectionPoint) {
    return Logger.getLogger( injectionPoint.getMember().getDeclaringClass().getName() );    
}

The container must provide a bean with scope @Dependent, bean type InjectionPoint and qualifier @Default, allowing dependent objects, as defined in Section 6.4.1, “Dependent objects”, to obtain information about the injection point to which they belong. The built-in implementation must be a passivation capable dependency, as defined in Section 6.6.2, “Passivation capable dependencies”.

If a bean that declares any scope other than @Dependent has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error.

If a Java EE component class supporting injection that is not a bean has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error.

The Instance interface provides a method for obtaining instances of beans with a specified combination of required type and qualifiers, and inherits the ability to iterate beans with that combination of required type and qualifiers from java.lang.Iterable:

public interface Instance<T> extends Iterable<T>, Provider<T> {
      
    public Instance<T> select(Annotation... qualifiers);
    public <U extends T> Instance<U> select(Class<U> subtype, Annotation... qualifiers);
    public <U extends T> Instance<U> select(TypeLiteral<U> subtype, Annotation... qualifiers);
    
    public boolean isUnsatisfied();
    public boolean isAmbiguous();
      
}

For an injected Instance:

For example, this injected Instance has required type PaymentProcessor and required qualifier @Any:

@Inject @Any Instance<PaymentProcessor> anyPaymentProcessor;

The select() method returns a child Instance for a given required type and additional required qualifiers. If no required type is given, the required type is the same as the parent.

For example, this child Instance has required type AsynchronousPaymentProcessor and additional required qualifier @Asynchronous:

Instance<AsynchronousPaymentProcessor> async = anyPaymentProcessor.select( 
            AsynchronousPaymentProcessor.class, new AsynchronousQualifier() );

If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.

If an instance of an annotation that is not a qualifier type is passed to select(), an IllegalArgumentException is thrown.

The get() method must:

The iterator() method must:

The method isUnsatisfied() returns true if there is no bean that has the required type and qualifiers and is eligible for injection into the class into which the parent Instance was injected, or false otherwise.

The method isAmbiguous() returns true if there is more than one bean that has the required type and qualifiers and is eligible for injection into the class into which the parent Instance was injected, or false otherwise.

The container must provide a built-in bean with:

The built-in implementation must be a passivation capable dependency, as defined in Section 6.6.2, “Passivation capable dependencies”.

javax.enterprise.util.AnnotationLiteral makes it easier to specify qualifiers when calling select():

public PaymentProcessor getSynchronousPaymentProcessor(PaymentMethod paymentMethod) {
    
    class SynchronousQualifier extends AnnotationLiteral<Synchronous>
            implements Synchronous {}
    
    class PayByQualifier extends AnnotationLiteral<PayBy>
            implements PayBy {
        public PaymentMethod value() { return paymentMethod; }
    }
    
    return anyPaymentProcessor.select(new SynchronousQualifier(), new PayByQualifier()).get();
}

javax.enterprise.util.TypeLiteral makes it easier to specify a parameterized type with actual type parameters when calling select():

public PaymentProcessor<Cheque> getChequePaymentProcessor() {
    PaymentProcessor<Cheque> pp = anyPaymentProcessor
        .select( new TypeLiteral<PaymentProcessor<Cheque>>() {} ).get();
}