You can refer to resources that are instantiated and bound to CDI as contextual instances . When an application is
deployed and enabled, a contextual instance of a resource that is denoted as ApplicationScoped can be created,
and that same resource can be destroyed when an application is undeployed or disabled. The application developer
does not need to do anything to manage the scope of such resources; the container simply takes care of the scope
management. Similarly, a resource that is denoted as SessionScoped can be instantiated when a session begins, and
then once the session ends, that resource will be destroyed. Contextual scoping makes CDI a very important piece of
Java applications, especially for resource management.
Also mentioned in the introduction, the DI portion of CDI refers to the ability to inject resources, or contextual
instances , into other resources. By use of dependency injection, objects and resources can be injected into other
objects that are referred to as injection targets . Those injected objects and resources maintain their context, and
therefore, if one SessionScoped managed bean is injected into another, all of the session-specific information is
available and can be accessed/updated as needed.
CDI is one of those technologies that has a tendency to be a game changer, making the life of a programmer
much easier once all of its benefits are utilized. This chapter will briefly cover some of the most widely used portions
of CDI and delve into the enhancements that have been made in CDI 1.1.
The concept of dependency injection greatly reduces the amount of overhead that is necessary for a developer to gain
reference to a Java object from within another Java class. The Java EE stack makes it very easy to gain reference to just
about any Java object from within another class. Dependency injection refers to the ability to inject components into
an application in a type-safe manner, including the ability to choose at deployment time which implementation of
a particular interface to inject. CDI allows almost any Java class to be injected into another with very little configuration.
This ability increases the usability of resources since such resource can be referenced from any number of different
classes and maintain the same state wherever they are being used. In reality, just about any object can be injected
anywhere with CDI. The following are some Java objects that can be injected:
Almost any Java class
Java EE resources, including data sources, JMS topics, queues, and connection factories
Objects returned by producer methods
Web service references
To inject a resource into another, the application module or JAR file must contain a META-INF directory
that includes a beans.xml configuration file. The beans.xml file may or may not be empty depending upon the
configuration. However, for the purposes of this example (and for most general CDI use cases), the beans.xml file is
usually an empty configuration file that is used as a placeholder to tell Java EE that the application wants to use CDI.
Remote EJB references
In previous versions of java ee, most configuration and deployments were accomplished via xML.