An unsatisfied dependency exists at an injection point when no enabled Web Bean has the API type and binding types declared by the injection point.

An ambiguous dependency exists at an injection point when in the set of enabled Web Beans with the API type and binding types declared by the injection point there exists no unique Web Bean with a higher precedence than all other Web Beans in the set.

The Web Bean manager must validate all injection points of all enabled Web Beans at initialization time to ensure that there are no unsatisfied or ambiguous dependencies. If an unsatisfied or ambiguous dependency exists, an UnsatisfiedDependencyException or AmbiguousDependencyException is thrown by the Web Bean manager at initialization time, as defined in Section 4.9, “Instance resolution”.

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 Web Bean manager 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 Web Bean that may be null, such as a producer method with a nullable (non-primitive) return type, a NullableDependencyException is thrown by the Web Bean manager at initialization time.

The method Bean.isNullable() may be used to detect if a Web Bean has null values.

References to Web Bean instances are valid only for a certain period of time. The application should not invoke a method of an invalid reference.

The validity of an injected reference depends upon whether the scope of the injected Web Bean is a normal scope or a pseudo-scope.

Clients of a Web Bean with a normal scope type, as defined in Section 8.2, “Normal scopes and pseudo-scopes”, do not hold a direct reference to the instance of the Web Bean (the object returned by Bean.create()). Instead, their reference is to a client proxy object. A client proxy implements/extends all API types of the Web Bean and delegates all method calls to the current instance (as defined in Section 8.2, “Normal scopes and pseudo-scopes”) of the Web Bean.

There are a number of reasons for this indirection:

Client proxies are never required for a Web Bean whose scope is a pseudo-scope such as @Dependent.

All client proxies must be serializable.

Client proxies may be shared between multiple injection points. For example, a particular Web Bean manager might instantiate exactly one client proxy object per Web Bean. (However, this strategy is not required by the Web Beans specification.)

If an injection point declares no binding type, the default binding type @Current is assumed.

The following are equivalent:

@ConversationScoped
public class Order {
   
   private Product product;
   private User customer;
   
   @Initializer
   public void init(@Selected Product product, User customer)
   {
       this.product = product;
       this.customer = customer;
   }

}

@ConversationScoped
public class Order {
   
   private Product product;
   private User customer;
   
   @Initializer
   public void init(@Selected Product product, @Current User customer)
   {
       this.product = product;
       this.customer = customer;
   }

}

As are the following:

<myapp:Order>
    <ConversationScoped/>
    
    <myapp:init>
        <Initializer/>
        <myapp:Product>
            <myapp:Selected/>
        </myapp:Product>
        <myapp:User/>
    </myapp:init>

</myapp:Order>

<myapp:Order>
    <ConversationScoped/>
    
    <myapp:init>
        <Initializer/>
        <myapp:Product>
            <myapp:Selected/>
        </myapp:Product>
        <myapp:User>
            <Current/>
        </myapp:User>
    </myapp:init>

</myapp:Order>

The following definitions are equivalent:

public class Payment {

   public Payment(BigDecimal amount) { ... }
   
   @Initializer Payment(Order order) { 
      this(order.getAmount(); 
   }

}

public class Payment {

   public Payment(BigDecimal amount) { ... }
   
   @Initializer Payment(@Current Order order) { 
      this(order.getAmount(); 
   }

}

As are the following:

<myapp:Payment>
    <myapp:Order/>
</myapp:Payment>

<myapp:Payment>
    <myapp:Order>
        <Current/>
    </myapp:Order>
</myapp:Payment>

The Java language does not currently support a literal syntax for parameterized types. Therefore, Web Beans provides the following helper class to allow inline instantiation of an object that represents a parameterized type.

public abstract class TypeLiteral<T> {

	protected TypeLiteral() {
		if (!(getClass().getSuperclass() == TypeLiteral.class)) {
			throw new RuntimeException("Not a direct subclass of TypeLiteral");
		}
		if (!(getClass().getGenericSuperclass() instanceof ParameterizedType)) {
			throw new RuntimeException("Missing type parameter in TypeLiteral");
		}
	}

	public final Type getType() {
		ParameterizedType parameterized = (ParameterizedType) getClass()
				.getGenericSuperclass();
		return parameterized.getActualTypeArguments()[0];
	}

	@SuppressWarnings("unchecked")
	public final Class<T> getRawType() {
		Type type = getType();
		if (type instanceof Class) {
			return (Class<T>) type;
		} else if (type instanceof ParameterizedType) {
			return (Class<T>) ((ParameterizedType) type).getRawType();
		} else if (type instanceof GenericArrayType) {
			return (Class<T>) Object[].class;
		} else {
			throw new RuntimeException("Illegal type parameter in TypeLiteral");
		}
	}
	
}

An object that represents any parameterized type may be obtained by subclassing TypeLiteral.

TypeLiteral type = new TypeLiteral<List<String>>() {};

This object may be passed to Web Beans APIs that perform typesafe resolution.

The Java language does not currently support a literal syntax for inline instantiation of annotation values. Therefore, Web Beans provides the following helper class to allow inline instantiation of annotation type instances.

public abstract class AnnotationLiteral<T extends Annotation> 
        implements Annotation {

	protected AnnotationLiteral() {
		if (!(getClass().getSuperclass() == AnnotationLiteral.class)) {
			throw new RuntimeException(
					"Not a direct subclass of AnnotationLiteral");
		}
		if (!(getClass().getGenericSuperclass() instanceof ParameterizedType)) {
			throw new RuntimeException(
					"Missing type parameter in AnnotationLiteral");
		}
	}

	@SuppressWarnings("unchecked")
	public final Class<T> annotationType() {
		ParameterizedType parameterized = (ParameterizedType) getClass()
				.getGenericSuperclass();
		return (Class<T>) parameterized.getActualTypeArguments()[0];
	}
}

An instance of an annotation type may be obtained by subclassing AnnotationLiteral.

public abstract class PayByBinding 
    extends AnnotationLiteral<PayBy> 
    implements PayBy {}

PayBy payby = new PayByBinding() { public value() { return CHEQUE; } };

Annotation values are often passed to Web Beans APIs that perform typesafe resolution.

Occasionally, the application might need to obtain a Web Bean instance via programmatic API call. This is useful when the type or binding types vary dynamically—in generic framework code, for example. Thus, the Manager interface provides operations for resolving a Web Bean by type or name. The Web Bean manager provides an implementation of this interface to the application.

The Web Bean manager provides a built-in Web Bean with API type javax.webbeans.Manager, scope @Dependent, deployment type @Standard and binding type @Current. Thus, any Web Bean may obtain an instance of Manager by injecting it:

@Current Manager manager;

Alternatively, the application may obtain the Manager object from JNDI. The Web Bean manager must register an instance of Manager with name java:comp/Manager in JNDI at initialization time.

A contextual instance of a Web Bean may be obtained by calling Manager.getInstance(), passing the Bean object representing the Web Bean.

public interface Manager {
    
    public <T> T getInstance(Bean<T> bean);
    
    ...
    
}

Manager.getInstance() returns a Web Bean instance or client proxy.

The Manager.getInstanceByType() methods obtain a contextual instance of a Web Bean:

public interface Manager {
    
    public <T> T getInstanceByType(Class<T> type, Annotation... bindingTypes);
    public <T> T getInstanceByType(TypeLiteral<T> type, Annotation... bindingTypes);
    
    ...
    
}

The first argument is a Web Bean API type, the remaining arguments are instances of binding annotation types.

For example:

PaymentProcessor pp = manager.getInstanceByType(PaymentProcessor.class, 
        synchronousAnnotation, 
        payByAnnotation);

If no binding annotations are passed to getInstanceByType(), the default binding type @Current is assumed.

If two instances of the same binding type are passed to getInstanceByType(), a DuplicateBindingTypeException is thrown.

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

The getInstanceByType() method must:

The getInstanceByType() method is called whenever the Web Bean manager injects a Web Bean instance into another Web Bean.

public class SynchronousBinding 
          extends AnnotationLiteral<Synchronous> 
          implements Synchronous {}

public abstract class PayByBinding 
          extends AnnotationLiteral<PayBy> 
          implements PayBy {}

PaymentProcessor pp = manager.getInstanceByType(PaymentProcessor.class, 
            new SynchronousBinding(),
            new PayByBinding() { public PaymentMethod value() { return CHEQUE; } });

PaymentProcessor pp = manager.getInstanceByType( new TypeLiteral<List<String>>() {}, 
            new WishListBinding() );

public interface Manager {
    
    public <T> Set<Bean<T>> resolveByType(Class<T> apiType, Annotation... bindingTypes);
    public <T> Set<Bean<T>> resolveByType(TypeLiteral<T> apiType, Annotation... bindingTypes);
    
    ...
    
}

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

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

@PayBy(CHEQUE) PaymentProcessor paymentProcessor;

@PayBy(CREDIT_CARD) PaymentProcessor paymentProcessor;

@BindingType
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface PayBy {
    PaymentMethod value();
    @NonBinding String comment();
}

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

@PayBy(CHEQUE) PaymentProcessor paymentProcessor;

@Synchronous PaymentProcessor paymentProcessor;

@Synchronous @PayBy(CHEQUE) PaymentProcessor paymentProcessor;

The Web Bean manager provides a Unified EL ELResolver. When this resolver is called with a null base object, it calls the method Manager.getInstanceByName() to obtain an instance of the Web Bean named in the EL expression:

public interface Manager {
    
    public Object getInstanceByName(String name);
    
    ...
    
}

For example:

Object pp = manager.getInstanceByName("paymentProcessor");

The getInstanceByName() method must:

For each distinct name that appears in the EL expression, getInstanceByName() must be called at most once. Even if a name appears more than once in the same expression, the Web Bean manager may not call getInstanceByName() multiple times with that name. This restriction ensures that there is a unique instance of each Web Bean with scope @Dependent in any EL evaluation.

Open issue: Web Beans supports qualified names. The ELResolver implements support for qualified names in Unified EL. How exactly does this work?

public interface Manager {
    
    public Set<Bean<?>> resolveByName(String name);
    
    ...
    
}