If a Web Bean does not explicitly declare a binding type, the Web Bean has exactly one binding type: javax.webbeans.Current. This is called the default binding type.

The following declarations are equivalent:

@Current
public class Order {}

public class Order {}

The default binding type is also assumed for any injection point that does not explicitly declare a binding type. The following declarations are equivalent:

public class Order {
    public Order(@Current OrderProcessor processor) { ... }
}

public class Order {
    public Order(OrderProcessor processor) { ... }
}

A binding type is a Java annotation defined as @Target({METHOD, FIELD, PARAMETER, TYPE}) and @Retention(RUNTIME). All binding types must specify the @BindingType meta-annotation.

For example:

@BindingType
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface Synchronous {}

@BindingType
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface Asynchronous {}

A binding annotation may define annotation members.

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

Binding annotation member values are significant to the typesafe resolution algorithm.

A Web Bean's binding types are declared by annotating the implementation class or producer method with the binding types.

@LDAP 
class LdapAuthenticator 
        implements Authenticator {
    ...
}

public class Shop {

   @Produces @All
   public List<Product> getAllProducts() { ... }

   @Produces @WishList
   public List<Product> getWishList() { ..... }
   
   @Produces @ShoppingCart
   public List<Product> getShoppingCart() { ..... }

}

Any Web Bean may declare multiple binding types.

@Synchronous @Reliable
class SynchronousReliablePaymentProcessor 
        implements PaymentProcessor {
    ...
}

If no binding type is explicitly specified, the default binding type is assumed.

If a Web Bean is declared in web-beans.xml, binding types may be specified using the binding type names:

<myapp:SynchronousPaymentProcessor>
    <myapp:Synchronous/>
    <myapp:Reliable/>
</myapp:SynchronousPaymentProcessor>

If any binding type is specified in XML, the binding annotations appearing on the implementation class or producer method are ignored and all binding types must be explicitly specified in XML.

Otherwise, if no binding types are specified in XML, the binding annotations that appear on the implementation class or producer method are used. If no binding annotations appear on the implementation class or producer method, the default binding type is used.

Binding annotations are applied to injected fields (see Section 3.6, “Injected fields”) to determine the Web Bean that is injected, according to the typesafe resolution algorithm defined in Section 4.9.2, “Typesafe resolution algorithm”.

@LDAP Authenticator authenticator;

A Web Bean may only be injected to an injection point if it has all the binding types of the injection point.

@Synchronous @Reliable PaymentProcessor paymentProcessor;

For the case of producer methods, the binding annotation help determine exactly which producer method is called:

@All List<Product> catalog;

@WishList List<Product> wishList;

@ShoppingCart List<Product> cart;

For a Web Bean defined in XML, the binding types of a field may be specified using XML:

<myapp:paymentProcessor>
    <myapp:Asynchronous/>
    <myapp:Reliable/>
</myapp:paymentProcessor>

When the binding types of a field are specified using XML, any binding type annotations of the field are ignored.

Binding annotations may be applied to parameters of producer methods, initializer methods, disposal methods, Web Bean remove methods or Web Bean constructors (see Chapter 3, Web Bean implementation) to determine the Web Bean instance that is passed when the method is called by the Web Bean manager. The Web Bean manager uses the typesafe resolution algorithm defined in Section 4.9.2, “Typesafe resolution algorithm” to determine values for these parameters.

For example, when the Web Bean manager encounters the following producer method, an instance of SynchronousPaymentProcessor will be passed to the first parameter and an instance of AsynchronousPaymentProcessor will be passed to the second parameter:

@Produces
PaymentProcessor getPaymentProcessor(@Synchronous PaymentProcessor sync, 
                                     @Asynchronous PaymentProcessor async) {
    return isSynchronous() ? sync : async;
}

For a Web Bean defined in XML, the binding types of a method parameter may be specified using XML:

<myapp:getPaymentProcessor>
    <Produces/>
    <myapp:PaymentProcessor>
        <myapp:Synchronous/>
    </myapp:PaymentProcessor>
    <myapp:PaymentProcessor>
        <myapp:Asynchronous/>
    </myapp:PaymentProcessor>
</myapp:getPaymentProcessor>

When the binding types of a parameter are specified using XML, any binding type annotations of the parameter are ignored.

There are several standard scope types defined by Web Beans. The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 8.5, “Context management for built-in scopes” represent the standard scopes defined by the Java Servlets specification. The @ConversationScoped annotation represents the Web Beans conversation scope defined in Section 8.5.4, “Conversation context lifecycle”. In addition, there is the @Dependent pseudo-scope for dependent objects, as defined in Section 8.3, “Dependent pseudo-scope”.

A Web Beans scope type is a Java annotation defined as @Target({TYPE, METHOD}) and @Retention(RUNTIME). All scope types must also specify the @ScopeType meta-annotation.

For example, the following annotation declares a "business process scope":

@ScopeType
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface BusinessProcessScoped {}

An application or third-party framework might provide a context implementation for this custom scope (see Section 8.6, “Context management for custom scopes”).

The Web Bean's scope is defined by annotating the implementation class or producer method with a scope type.

A Web Bean implementation class or producer method may specify at most one scope type annotation. If an implementation class or producer method specifies multiple scope type annotations, a DefinitionException is thrown by the Web Bean manager at startup time.

The following examples demonstrate the use of built-in scope types:

@RequestScoped
public class ProductList implements DataModel { ... }

public class Shop {

   @Produces @SessionScoped @WishList
   public List<Product> getWishList() { ..... }

   @Produces @ConversationScoped @ShoppingCart
   public List<Product> getShoppingCart() { ..... }

}

Likewise, a Web Bean with the custom business process scope may be declared by annotating it with the @BusinessProcessScoped annotation:

@BusinessProcessScoped
public class Order {
    ...
}

Alternatively, a scope type may be specified using a stereotype annotation, as defined in Section 2.7.2, “Declaring the stereotypes for a Web Bean using annotations”.

If the Web Bean is declared in web-beans.xml, the scope may be specified using the scope annotation type name:

<myapp:ProductList>
    <RequestScoped/>
</myapp:ProductList>

If more than one scope type is specified in XML, a DefinitionException is thrown by the Web Bean manager at initialization time.

If an implementation class or producer method with a scope type annotation is specified and if no scope type is explicitly specified in XML, the scope defined by the scope type annotation is used.

Alternatively, a scope type may be specified using a stereotype declared in XML, as defined in Section 2.7.3, “Declaring the stereotypes for a Web Bean using XML”.

When no scope is explicitly declared by annotating the implementation class or producer method, or by using XML, the scope of a Web Bean is defaulted.

The default scope for a Web Bean which does not explicitly declare a scope depends upon its declared stereotypes:

If a Web Bean explicitly declares a scope, any default scopes declared by stereotypes are ignored.

There are two standard deployment types defined by Web Beans: @Production and @Standard.

All standard Web Beans defined by this specification, and provided by the Web Bean manager, are defined using the @Standard deployment type. For example, the Conversation object defined in Section 8.5.4, “Conversation context lifecycle” and the Manager object defined in Section 4.8, “The Manager object” have this deployment type. No Web Bean may be declared with the @Standard deployment type unless explicitly required by this specification.

Application Web Beans may be defined using the @Production deployment type.

A Web Beans deployment type is a Java annotation defined as @Target({TYPE, METHOD}) and @Retention(RUNTIME). All deployment types must also specify the @DeploymentType meta-annotation.

Applications and third-party frameworks may define their own deployment types. For example, the following deployment type might identify Web Beans which are used only at a particular site at which the application is deployed:

@DeploymentType
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface Australian {}

This deployment type might be used by a third-party framework that extends Web Beans:

@DeploymentType
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface DaoFramework {}

This deployment type might be used to define mock objects for integration testing:

@DeploymentType
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface Mock {}

The deployment type of the Web Bean is declared by annotating the implementation class or producer method.

An implementation class or producer method may specify at most one deployment type. If multiple deployment type annotations are specified, a DefinitionException is thrown by the Web Bean manager at initialization time.

Open issue: is this too restrictive? We could allow multiple deployment types to be specified, and ignore all but the highest-precedence enabled deployment type.

This Web Bean has the deployment type @Production:

@Production
public class Order {}

This Web Bean has the deployment type @Mock:

@Mock
public class MockOrder extends Order {}

By default, if no deployment type annotation is explicitly specified, a producer method inherits the deployment type of the Web Bean in which it is defined.

This producer method has the deployment type @Production:

@Production
public class Login {

   @Produces
   public User getUser() { ... }

}

This producer method has the deployment type @Australian:

@Production
public class TaxPolicies {

   @Produces @Australian
   public TaxPolicy getAustralianTaxPolicy() { ... }

}

Alternatively, a deployment type may be specified using a stereotype annotation, as defined in Section 2.7.2, “Declaring the stereotypes for a Web Bean using annotations”.

When a Web Bean is declared in web-beans.xml, the deployment type may be specified using a tag with the annotation type name:

<myapp:AustralianTaxPolicy>
    <deployment:Australian/>
</myapp:AustralianTaxPolicy>

If more than one deployment type is specified in XML, a DefinitionException is thrown by the Web Bean manager at initialization time.

If an implementation class or producer method with a deployment type annotation is specified and if no deployment type is explicitly specified in XML, the deployment type defined by the deployment type annotation is used.

Alternatively, a deployment type may be specified using a stereotype declared in XML, as defined in Section 2.7.3, “Declaring the stereotypes for a Web Bean using XML”.

When no deployment type is explicitly declared by annotating the implementation class or producer method, or by use of XML, the deployment type is defaulted.

The default deployment type for a Web Bean which does not explicitly declare a deployment type depends upon its declared stereotypes:

Thus, the following declarations are equivalent:

@Production
public class Order {}

public class Order {}

If a Web Bean explicitly declares a deployment type, any default deployment type declared by stereotypes are ignored.

In a particular deployment, only some deployment types are enabled. Web Beans declared with a deployment type that is not enabled are not available to the resolution algorithms defined in Chapter 4, Lookup, dependency injection and EL resolution.

The Web Bean manager inspects the deployment type of each Web Bean that exists in a particular deployment (see Section 10.1, “Web Bean discovery”) to determine whether the Web Bean is enabled in this deployment. If the deployment type is enabled, an instance of the Web Bean may be obtained by lookup, injection or EL resolution. Otherwise, the Web Bean is never instantiated by the Web Bean manager.

By default, only the built-in deployment types are enabled. To enable a custom deployment type, a <Deploy> element must be included in a web-beans.xml file and the deployment type must be declared using the annotation type name.

<WebBeans>
    <Deploy>
        <Standard/>
        <Production/>
        <myfwk:DaoFramework/>
        <deployment:Australian/>
        <myfwk:Mock/>
    </Deploy>
</WebBeans>

If a <Deploy> element is specified, only the explicitly declared deployment types are enabled. The @Standard deployment type must be declared. If the @Standard deployment type is not declared, a DeploymentException is thrown by the Web Bean manager at initialization time.

If no <Deploy> element is specified in any web-beans.xml file, only the @Standard and @Production deployment types are enabled.

If the <Deploy> element is specified in more than one web-beans.xml document, a DeploymentException is thrown by the Web Bean manager at initialization time.

In a particular deployment, all enabled deployment types are strongly ordered in terms of precedence. The precedence of a deployment type is used by the resolution algorithms defined in Chapter 4, Lookup, dependency injection and EL resolution.

If a <Deploy> element is specified, the order of the deployment type declarations determines the deployment type precedence. Deployment types which appear later in this list have a higher precedence than deployment types which appear earlier. The @Standard deployment type must appear first and always has the lowest precedence of any deployment type.

If no <Deploy> element is specified, the @Production deployment type has a higher precedence than the @Standard deployment type.

To specify the name of a Web Bean, the @Named annotation is applied to the implementation class or producer method. This Web Bean is named products:

@Named("products")
public class ProductList implements DataModel { ... }

If the @Named annotation does not specify the value member, the default name is assumed.

If the Web Bean is declared in web-beans.xml, the name may be specified using <Named>:

<myapp:ProductList>
    <Named>products</Named>
</myapp:ProductList>

If the <Named> element is empty, the default name is assumed.

If an implementation class or producer method with a @Named annotation is specified, and if no <Named> element is explicitly specified, the name specified by the @Named annotation is used. If the @Named annotation does not specify the value member, the default name is assumed.

If a <Named> element is specified, the @Named annotation is ignored.

In the following circumstances, a default name must be assigned by the Web Bean manager:

The default name for a Web Bean depends upon the Web Bean implementation. The rules for determining the default name for a Web Bean are defined in Chapter 3, Web Bean implementation.

If neither <Named> nor @Named is specified, by the Web Bean or its stereotypes, a Web Bean has no name.

A Web Beans stereotype is a Java annotation defined as @Target({TYPE, METHOD}), @Target(METHOD) or @Target(TYPE) and @Retention(RUNTIME). All stereotypes must also specify the @Stereotype meta-annotation.

A stereotype may declare at most one scope type. If a stereotype declares more than one scope type, a DefinitionException is thrown by the Web Bean manager at initialization time.

A stereotype may declare at most one deployment type. If a stereotype declares more than one deployment type, a DefinitionException is thrown by the Web Bean manager at initialization time.

A stereotype may declare an empty @Named annotation. If a stereotype declares a non-empty @Named annotation, a DefinitionException is thrown by the Web Bean manager at initialization time.

A stereotype may declare zero, one or multiple interceptor binding types, as defined in Section 6.2.4, “Interceptor bindings”.

A stereotype may not declare any binding type annotation. If a stereotype declares a binding type annotation, a DefinitionException is thrown by the Web Bean manager at initialization time.

For example, the following stereotype might be used to identify action classes in a web application:

@RequestScoped
@Production
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

Then actions would have scope @RequestScoped and deployment type @Production unless the scope or deployment type explicitly specified by the Web Bean.

We may specify interceptor bindings that apply to all actions:

@RequestScoped
@Secure
@Transactional
@Production
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

We may specify that every Web Bean with the stereotype has a defaulted name when a name is not explicitly specified by the Web Bean:

@RequestScoped
@Secure
@Transactional
@Named
@Production
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

If all actions are request scoped, we can make this restriction explicit:

@RequestScoped
@Secure
@Transactional
@Production
@Stereotype(supportedScopes=RequestScoped.class)
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

We may even require that all actions extend some ActionBase class:

@RequestScoped
@Secure
@Transactional
@Production
@Stereotype(requiredTypes=ActionBase.class)
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

Stereotype annotations may be applied to a Web Bean implementation class or producer method.

@Action
public class LoginAction { ... }

The default deployment type and default scope declared by the stereotype may be overridden by the Web Bean:

@Mock @ApplicationScoped @Action
public class MockLoginAction extends LoginAction { ... }

Multiple stereotypes may be applied to the same Web Bean:

@Dao @Action
public class LoginAction { ... }

If the Web Bean is declared in web-beans.xml, stereotypes may be declared using the stereotype annotation type name:

<myapp:LoginAction>
    <myfwk:Action/>
</myapp:LoginAction>

If any stereotype is specified in XML, the stereotypes appearing on the implementation class or producer method are ignored and all stereotypes must be explicitly specified in XML.

Otherwise, if no stereotypes are specified in XML, the stereotype annotations that appear on the implementation class or producer method are used. If no stereotype annotations appear on the implementation class or producer method, the Web Bean has no stereotypes.

A stereotype may place certain restrictions upon the Web Beans that declare the stereotype.

If a stereotype declares a requiredType, and the Web Bean API types do not include the type, a DefinitionException is thrown by the Web Bean manager at initialization time.

If a stereotype explicitly declares a set of scope types using supportedScopes, and the Web Bean scope is not in that set, a DefinitionException is thrown by the Web Bean manager at initialization time.

If a Web Bean declares multiple stereotypes, it must satisfy every restriction declared by every declared stereotype.

Web Beans provides a built-in stereotype. The @Model stereotype is intended for use with Web Beans that define the model layer of an MVC web application architecture such as JSF:

@Named
@RequestScoped
@Stereotype
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface Model {}

In addition, the special-purpose @Interceptor and @Decorator stereotypes are defined in Chapter 6, Interceptors and decorators.

The @Specializes annotation or <Specializes> XML element is used to indicate that one Web Bean directly specializes another Web Bean.

Formally, a Web Bean X is said to specialize another Web Bean Y if either:

If X specializes Y but does not directly specialize Y, we say that X indirectly specializes Y.

If, in a particular deployment, a Web Bean with a certain API type and set of binding types is not specialized by any other enabled Web Bean, we call it the most specialized Web Bean for that combination of type and binding types in that deployment.

Any producer methods, disposal methods (see Section 3.4.6, “Disposal methods”) or observer methods (see Section 7.5, “Observer methods”) declared by a Web Bean are invoked upon an instance of the most specialized enabled Web Bean that specializes the Web Bean, as defined by Section 5.6, “Lifecycle of producer methods” and Section 7.4, “Observer invocation”.

If, in a particular deployment, either

we say that inconsistent specialization exists, and an InconsistentSpecializationException is thrown by the Web Bean manager at initialization time.