A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions:

All Java classes that meet these conditions are managed beans and thus no special declaration is required to define a managed bean.

The unrestricted set of bean types for a managed bean contains the bean class, every superclass and all interfaces it implements directly or indirectly.

Note the additional restrictions upon bean types of beans with normal scopes defined in Section 5.4.1, “Unproxyable bean types”.

A managed bean with a constructor that takes no parameters does not require any special annotations. The following classes are beans:

public class Shop { .. }

class PaymentProcessorImpl implements PaymentProcessor { ... }

If the managed bean does not have a constructor that takes no parameters, it must have a constructor annotated @Inject. No additional special annotations are required.

A bean class may specify a scope, name, stereotypes and/or qualifiers:

@ConversationScoped @Default
public class ShoppingCart { ... }

A managed bean may extend another managed bean:

@Named("loginAction")
public class LoginAction { ... }

@Mock
@Named("loginAction")
public class MockLoginAction extends LoginAction { ... }

The second bean is a "mock object" that overrides the implementation of LoginAction when running in an embedded EJB Lite based integration testing environment.

If a bean class of a managed bean X is annotated @Specializes, then the bean class of X must directly extend the bean class of another managed bean Y. Then X directly specializes Y, as defined in Section 4.3, “Specialization”.

If the bean class of X does not directly extend the bean class of another managed bean, the container automatically detects the problem and treats it as a definition error.

For example, MockLoginAction directly specializes LoginAction:

public class LoginAction { ... }

@Mock @Specializes
public class MockLoginAction extends LoginAction { ... }

The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case.

For example, if the bean class is named ProductList, the default bean EL name is productList.

If a session bean is a stateful session bean:

If the application directly calls an EJB remove method of a contextual instance of a session bean that is a stateful session bean and declares any scope other than @Dependent, an UnsupportedOperationException is thrown.

If the application directly calls an EJB remove method of a contextual instance of a session bean that is a stateful session bean and has scope @Dependent then no parameters are passed to the method by the container. Furthermore, the container ignores the instance instead of destroying it when Contextual.destroy() is called, as defined in Section 7.3.2, “Lifecycle of stateful session beans”.

The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a bean class local view, the unrestricted set of bean types contains the bean class and all superclasses. In addition, java.lang.Object is a bean type of every session bean.

Remote interfaces are not included in the set of bean types.

A session bean does not require any special annotations apart from the component-defining annotation (or XML declaration) required by the EJB specification. The following EJBs are beans:

@Singleton
class Shop { .. }

@Stateless
class PaymentProcessorImpl implements PaymentProcessor { ... }

A bean class may also specify a scope, name, stereotypes and/or qualifiers:

@ConversationScoped @Stateful @Default @Model
public class ShoppingCart { ... }

A session bean class may extend another bean class:

@Stateless
@Named("loginAction")
public class LoginActionImpl implements LoginAction { ... }

@Stateless
@Mock
@Named("loginAction")
public class MockLoginActionImpl extends LoginActionImpl { ... }

If a bean class of a session bean X is annotated @Specializes, then the bean class of X must directly extend the bean class of another session bean Y. Then X directly specializes Y, as defined in Section 4.3, “Specialization”.

If the bean class of X does not directly extend the bean class of another session bean, the container automatically detects the problem and treats it as a definition error.

For example, MockLoginActionBean directly specializes LoginActionBean:

@Stateless
public class LoginActionBean implements LoginAction { ... }

@Stateless @Mock @Specializes
public class MockLoginActionBean extends LoginActionBean { ... }

The default name for a managed bean is the unqualified class name of the session bean class, after converting the first character to lower case.

For example, if the bean class is named ProductList, the default bean EL name is productList.

The bean types of a producer method depend upon the method return type:

Note the additional restrictions upon bean types of beans with normal scopes defined in Section 5.4.1, “Unproxyable bean types”.

A producer method may be declared by annotating a method with the @javax.enterprise.inject.Produces annotation.

public class Shop {
   @Produces PaymentProcessor getPaymentProcessor() { ... }
   @Produces List<Product> getProducts() { ... }
}

A producer method may also specify scope, name, stereotypes and/or qualifiers.

public class Shop {
   @Produces @ApplicationScoped @Catalog @Named("catalog") 
   List<Product> getProducts() { ... }
}

If a producer method is annotated @Inject, has a parameter annotated @Disposes, or has a parameter annotated @Observes, the container automatically detects the problem and treats it as a definition error.

If a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error.

Interceptors and decorators may not declare producer methods. If an interceptor or decorator has a method annotated @Produces, the container automatically detects the problem and treats it as a definition error.

A producer method may have any number of parameters. All producer method parameters are injection points.

public class OrderFactory {

   @Produces @ConversationScoped
   public Order createCurrentOrder(@New(Order.class) Order order, @Selected Product product) {
       order.setProduct(product);
       return order;
   }

}

If a producer method X is annotated @Specializes, then it must be non-static and directly override another producer method Y. Then X directly specializes Y, as defined in Section 4.3, “Specialization”.

If the method is static or does not directly override another producer method, the container automatically detects the problem and treats it as a definition error.

@Mock
public class MockShop extends Shop {

   @Override @Specializes
   @Produces 
   PaymentProcessor getPaymentProcessor() { 
      return new MockPaymentProcessor(); 
   }

   @Override @Specializes
   @Produces 
   List<Product> getProducts() {
      return PRODUCTS;
   }
   
   ...

}

A disposer method allows the application to perform customized cleanup of an object returned by a producer method.

A disposer method must be a non-abstract method of a managed bean class or session bean class. A disposer method may be either static or non-static. If the bean is a session bean, the disposer method must be a business method of the EJB or a static method of the bean class.

A bean may declare multiple disposer methods.

Each disposer method must have exactly one disposed parameter, of the same type as the corresponding producer method return type. When searching for disposer methods for a producer method, the container considers the type and qualifiers of the disposed parameter. If a producer method declared by the same bean class is assignable to the disposed parameter, according to the rules of typesafe resolution defined in Section 5.2, “Typesafe resolution”, the container must call this method when destroying any instance returned by that producer method.

A disposer method may resolve to multiple producer methods declared by the bean class, in which case the container must call it when destroying any instance returned by any of these producer methods.

A disposer method may be declared by annotating a parameter @javax.enterprise.inject.Disposes. That parameter is the disposed parameter. Qualifiers may be declared by annotating the disposed parameter:

public class UserDatabaseEntityManager {

    @Produces @ConversationScoped @UserDatabase
    public EntityManager create(EntityManagerFactory emf) {
        return emf.createEntityManager();
    }
    
    public void close(@Disposes @UserDatabase EntityManager em) {
        em.close();
    }

}

If a method has more than one parameter annotated @Disposes, the container automatically detects the problem and treats it as a definition error.

If a disposer method is annotated @Produces or @Inject or has a parameter annotated @Observes, the container automatically detects the problem and treats it as a definition error.

If a non-static method of a session bean class has a parameter annotated @Disposes, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error.

Interceptors and decorators may not declare disposer methods. If an interceptor or decorator has a method annotated @Disposes, the container automatically detects the problem and treats it as a definition error.

In addition to the disposed parameter, a disposer method may declare additional parameters, which may also specify qualifiers. These additional parameters are injection points.

public void close(@Disposes @UserDatabase EntityManager em, @Logger Log log) { ... }

A disposer method is bound to a producer method if:

If there are multiple disposer methods for a single producer method, the container automatically detects the problem and treats it as a definition error.

If there is no producer method declared by the bean class that is assignable to the disposed parameter of a disposer method, the container automatically detects the problem and treats it as a definition error.

The default name for a producer method is the method name, unless the method follows the JavaBeans property getter naming convention, in which case the default name is the JavaBeans property name.

For example, this producer method is named products:

@Produces @Named
public List<Product> getProducts() { ... }

This producer method is named paymentProcessor:

@Produces @Named
public PaymentProcessor paymentProcessor() { ... }

The bean types of a producer field depend upon the field type:

Note the additional restrictions upon bean types of beans with normal scopes defined in Section 5.4.1, “Unproxyable bean types”.

A producer field may be declared by annotating a field with the @javax.enterprise.inject.Produces annotation.

public class Shop {
   @Produces PaymentProcessor paymentProcessor = ....;
   @Produces List<Product> products = ....;
}

A producer field may also specify scope, name, stereotypes and/or qualifiers.

public class Shop {
   @Produces @ApplicationScoped @Catalog @Named("catalog") 
   List<Product> products = ....;
}

If a producer field is annotated @Inject, the container automatically detects the problem and treats it as a definition error.

If a non-static field of a session bean class is annotated @Produces, the container automatically detects the problem and treats it as a definition error.

Interceptors and decorators may not declare producer fields. If an interceptor or decorator has a field annotated @Produces, the container automatically detects the problem and treats it as a definition error.

The default name for a producer field is the field name.

For example, this producer field is named products:

@Produces @Named
public List<Product> products = ...;

A resource may be declared by specifying a Java EE component environment injection annotation as part of a producer field declaration. The producer field may be static.

The injection annotation specifies the metadata needed to obtain the resource, entity manager, entity manager factory, remote EJB instance or web service reference from the component environment.

@Produces @WebServiceRef(lookup="java:app/service/PaymentService")
PaymentService paymentService;

@Produces @EJB(ejbLink="../their.jar#PaymentService")
PaymentService paymentService;

@Produces @Resource(lookup="java:global/env/jdbc/CustomerDatasource")
@CustomerDatabase Datasource customerDatabase;

@Produces @PersistenceContext(unitName="CustomerDatabase")
@CustomerDatabase EntityManager customerDatabasePersistenceContext;

@Produces @PersistenceUnit(unitName="CustomerDatabase")
@CustomerDatabase EntityManagerFactory customerDatabasePersistenceUnit;

The bean type and qualifiers of the resource are determined by the producer field declaration.

If the producer field declaration specifies an EL name, the container automatically detects the problem and treats it as a definition error.

If the matching object in the Java EE component environment is not of the same type as the producer field declaration, the container automatically detects the problem and treats it as a definition error.

The unrestricted set of bean types of a resource is determined by the declared type of the producer field, as specified by Section 3.4.1, “Bean types of a producer field”.

The bean constructor may be identified by annotating the constructor @Inject.

@SessionScoped
public class ShoppingCart implements Serializable {

   private User customer;
   
   @Inject
   public ShoppingCart(User customer) {
       this.customer = customer;
   }
   
   public ShoppingCart(ShoppingCart original) {
       this.customer = original.customer;
   }
   
   ShoppingCart() {}
   
   ...

}

@ConversationScoped
public class Order {

   private Product product;
   private User customer;

   @Inject
   public Order(@Selected Product product, User customer) {
       this.product = product;
       this.customer = customer;
   }
   
   public Order(Order original) {
       this.product = original.product;
       this.customer = original.customer;
   }
   
   Order() {}
   
   ...

}

If a bean class does not explicitly declare a constructor using @Inject, the constructor that accepts no parameters is the bean constructor.

If a bean class has more than one constructor annotated @Inject, the container automatically detects the problem and treats it as a definition error.

If a bean constructor has a parameter annotated @Disposes, or @Observes, the container automatically detects the problem and treats it as a definition error.

A bean constructor may have any number of parameters. All parameters of a bean constructor are injection points.

An injected field may be declared by annotating the field @javax.inject.Inject.

@ConversationScoped
public class Order {
   
   @Inject @Selected Product product;
   @Inject User customer;

}

If an injected field is annotated @Produces, the container automatically detects the problem and treats it as a definition error.

An initializer method may be declared by annotating the method @javax.inject.Inject.

@ConversationScoped
public class Order {
   
   private Product product;
   private User customer;

   @Inject 
   void setProduct(@Selected Product product) {
       this.product = product;
   }
   
   @Inject 
   public void setCustomer(User customer) {
       this.customer = customer;
   }

}

If a generic method of a bean is annotated @Inject, the container automatically detects the problem and treats it as a definition error.

If an initializer method is annotated @Produces, has a parameter annotated @Disposes, or has a parameter annotated @Observes, the container automatically detects the problem and treats it as a definition error.

An initializer method may have any number of parameters. All initializer method parameters are injection points.