Java Reference
In-Depth Information
As you can see in
figure 12.1
, CDI sits as the bridge layer between JSF and the managed
beans. With the release of Java EE 7, CDI is now specified in JSR-346.
12.1.1. CDI services
CDI provides a core set of services that are built around the concepts of contexts and de-
pendency injection. Contexts, which we'll define in more depth shortly, can be viewed
as well-defined lifecycle scopes. You've already seen dependency injection in earlier
chapters, but CDI takes DI to a new level. Earlier you used EJB 3 dependency injection to
inject database connections, JPA persistence contexts, and references to other EJBs. This
was accomplished via specific annotations such as
@Resource
,
@PersistenceCon-
text
, and
@EJB
. EJB 3 dependency injection is limited to only EJBs; you can't perform
injection into any POJO or inject a non-EJB into an EJB. CDI's dependency injection
doesn't have these limitations, as you'll see.
CDI is an object container that can be used as a standalone or within an existing Java EE
container. Although we've touched on the two main features of CDI, the CDI container
provides a lifecycle for stateful objects, binding of objects to well-defined contexts, type-
safe dependency injection, an event notification facility, and robust interceptors. Let's look
at each of these services separately.
Lifecycle for stateful objects
CDI provides a well-defined lifecycle for its beans. CDI is an extension of the managed
beans specification and thus provides a number of hooks for controlling the creation of
new objects, as well as notification of object destruction. The capabilities specified in the
managed bean specification are limited; specification is merely a reformulation of the lim-
itations of JSF-backing beans. The specification doesn't preclude extensions and it encour-
ages enhancements.
CDI extends the managed beans specification by expanding the modes by which a bean
can be instantiated. The requirement that a bean possess a no-argument constructor is re-
laxed. Beans can be constructed using a constructor that takes arguments. The parameters
will be “injected” into the constructor. In addition, producer methods can be defined that
will construct an instance of a bean. This enables the factory pattern for bean creation and
thus greatly increases the flexibility.
