Java Reference
In-Depth Information
progenitor of CDI was an open source project from JBoss called Seam. Seam attempted
to simplify Java EE development by enabling JSF to directly use and invoke EJB, as well
as by providing components—basically Java beans—that were defined using annotations
and injected. Seam also included support for generating and sending emails, business pro-
cess integration, and context. Seam's context feature included support for a conversational
context, which greatly simplifies web application development for tabbed web browsers.
When Seam was introduced, Java EE had negligible support for dependency injection (DI).
At the same time, Spring was upending traditional Java EE development and challenging
the standard Java EE containers. Spring demonstrated the power of dependency injection
and the need for it in Java EE.
Although Seam greatly simplified Java EE development and made it possible to use EJBs
easily from JSF, Seam was still an add-on. To use Seam you still had to download and
configure it for your particular container. There were issues with some containers, so us-
ing Seam involved verifying that it would work with your specific container and possibly
working around issues specific to your container. The value provided by Seam, combined
with competition from Spring and Google Guice, made the capabilities provided by Seam
too important to remain an external add-on. As a result, a JSR was initiated and many of
the core features from Seam were pulled into Java EE 6 as CDI.
Integrating the core features of Seam required explicitly defining a bean within the context
of Java EE. Prior to Java EE 6 there was no unified bean definition. At the time there were
two types of beans: JSF-backing beans and Enterprise Java Beans. To provide a common
definition, the concept of a managed bean was introduced with the managed bean specific-
ation. A managed bean is simply a POJO that's managed by a container, with the container
providing a basic set of services including resource injection, lifecycle callbacks, and in-
terceptors. A managed bean must have a no-argument constructor, not be serializable, and
possess a unique name. Managed beans are defined using the
@ManagedBean
annotation
with annotations for lifecycle callbacks:
@PostConstruct
and
@Destroy
. These re-
quirements, such as the no-argument constructor, can be relaxed by managed bean exten-
sions. EJBs, JSF-backing beans, and CDI beans are managed bean extensions.
CDI is much more than an extension to managed beans. It's a full-fledged object container
that can be used independently of Java EE. For example, CDI can be used in standalone
desktop JavaFX applications. With CDI, practically any POJO can be a managed bean; this
includes POJOs that lack no-argument constructors or require a special factory to be instan-
tiated. CDI doesn't provide a component model of its own. More importantly, CDI unifies
the JSF and EJB bean models, enabling JSF to use EJBs as backing beans. In some ways
