Contexts and Dependency Injection (CDI) for the Java EE platform is a feature that helps to bind together the web tier and the transactional tier of the Java EE platform. CDI is a set of services that, used together, make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications.
In CDI, a bean is a source of contextual objects that define application state and/or logic. A Java EE component is a bean if the lifecycle of its instances may be managed by the container according to the lifecycle context model defined in the CDI specification.
A managed bean is implemented by a Java class, which is called its bean class. A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE technology specification, such as the JavaServer Faces technology specification.
When we need to use a bean that injects another bean class in a web application, the bean needs to be able to hold state over the duration of the user’s interaction with the application. The way to define this state is to give the bean a scope. A scope gives an object a well-defined lifecycle context. A scoped object can be automatically created when it is needed and automatically destroyed when the context in which it was created ends. Moreover, its state is automatically shared by any clients that execute in the same context.
When we create a Java EE component that is a managed bean, it becomes a scoped object, which exists in a well-defined lifecycle context. The scopes provided by CDI are the following:
1. Request – @RequestScoped
This scope describes a user’s interaction with a web application in a single HTTP request. The instance of the
@RequestScoped annotated bean has an HTTP request lifecycle.
2. Session – @SessionScoped
This scope desrcibes a user’s interaction with a web application across multiple HTTP requests.
3. Application – @ApplicationScoped
In this case the state is shared across all users’ interactions with a web application. The container provides the same instance of the
@ApplicationScoped annotated bean to all client requests.
4. Conversation – @ConversationScoped
This scope describes a user’s interaction with a JavaServer Faces application, within explicit developer-controlled boundaries that extend the scope across multiple invocations of the JavaServer Faces lifecycle. All long-running conversations are scoped to a particular HTTP servlet session and may not cross session boundaries.
Note that with
ConversationScoped beans we achieve the same functionality we need from a
ViewScoped JSF bean. In addition, with the
ConversationScoped beans we can maintain the same conversation – or state – between distinct page requests. But when we leave a conversation without it, the managed bean will stay active until it times out.
A thing to notice here is that a CDI managed bean is injected into another bean by a reference to a proxy. The CDI container will not pass a reference to the injected bean itself but will instead pass a reference to a proxy. The proxy handles all calls to the injected bean transparently. For example, when we make calls to an injected
SessionScoped bean with distinct HTTP sessions, the proxy will be used to provide the bean instance to all the HTTP sessions.
Another thing to notice is that beans that use session or conversation scope must be serializable. This is because the container may need to free resources for an arbitrary reason and it may decide to persist a bean of this type into physical storage (or other persistent media type). When the persisted bean is once again needed for correct application execution, the container will fetch the bean and restore its state.
5. CDI pseudo-scopes
In addition to the four built-in scopes, CDI also supports two pseudo-scopes, as described in the next sections.
5.1 Singleton – @Singleton
The problem with this pseudo-scope is that
@Singleton annotated beans don’t have a proxy object. Clients hold a direct reference to the singleton instance. So we need to consider the case of a client that can be serialized, for example, any
@ConversationScoped bean, any dependent object of a
@ConversationScoped bean, or any statefull session bean. To ensure that the singleton bean remains a singleton when its client gets serialized we can have the singleton bean implement
readReplace() (as defined by the Java serialization specification), make sure the client keeps only a transient reference to the singleton bean, or give the client a reference of type
X is the bean type of the singleton bean.
5.2 Dependent – @Dependent
This pseudo-scope means that an object exists to serve exactly one client (bean) and has the same lifecycle as that client (bean). This is the default scope for a bean which does not explicitly declare a scope type. An instance of a dependent bean is never shared between different clients or different injection points. It is strictly a dependent object of some other object. It is instantiated when the object it belongs to is created, and destroyed when the object it belongs to is destroyed.
All predefined scopes except
@Dependent are contextual scopes. CDI places beans of contextual scope in the context whose lifecycle is defined by the Java EE specifications. For example, a session context and its beans exist during the lifetime of an HTTP session. Injected references to the beans are contextually aware. The references always apply to the bean that is associated with the context for the thread that is making the reference. The CDI container ensures that the objects are created and injected at the correct time as determined by the scope that is specified for these objects.
You can also define and implement custom scopes. They can be used by those who implement and extend the CDI specification.
This was a tutorial of all bean scoped provided by CDI.
Java Platform, Enterprise Edition is a widely used platform for enterprise server programming in the Java programming language.
This book covers exciting recipes on securing, tuning and extending enterprise applications using a Java EE 6 implementation.The book starts with the essential changes in Java EE 6. Then they will dive into the implementation of some of the new features of the JPA 2.0 specification, and look at implementing auditing for relational data stores.They will then look into how they can enable security for their software system using Java EE built-in features as well as using the well-known Spring Security framework. They will then look at recipes on testing various Java EE technologies including JPA, EJB, JSF, and Web services.Next they will explore various ways to extend a Java EE environment with the use of additional dynamic languages as well as frameworks.At the end of the book, they will cover managing enterprise application deployment and configuration, and recipes that will help you debug problems and enhance the performance of your applications.