Java Reference
In-Depth Information
Introducing Contexts and Dependency
CDI for the Java EE platform introduces a standard set of component management services
to the Java EE platform. As a component of Java EE 7, CDI is in many ways a standardiza-
tion of concepts that have been brewing in Spring for a long time, such as dependency in-
jection and interceptors. In fact, CDI and Spring 3 share many similar features. There are
also other dependency injection frameworks available for developers that are more light-
weight and easier to use in a Java SE environment. Google Guice (
google/guice ) is a notable example. Providing full-blown support for the CDI container in a
standalone Java SE application and separation from the application server are one of the
goals of the upcoming CDI 2.0 specification. This will allow developers to use a common
programming model on both client and server sides.
CDI lets you decouple concerns by what it refers to as loose coupling and strong typing. In
doing so, it provides an almost liberating escape from the banalities of everyday Java pro-
gramming, allowing injections of its objects and controlling their lifetimes.
Why is CDI required for Java EE?
If you have been programming with Java EE 5, you might argue that it already features re-
sources injection of resources. However, this kind of injection can be used only for re-
sources known to the container (for example, @EJB , @PersistenceContext , @Per-
sistenceUnit , and @Resource ). CDI, on the other hand, provides a general-purpose
dependency injection scheme, which can be used for any component.
The CDI elementary unit is still the bean. Compared to EJBs, CDI features a different,
more flexible kind of bean, which would often be a good place to put your business logic
in. One of the most important differences between the two approaches is that CDI Beans
are contextual ; that is, they live in a well-defined scope.
Consider the following code snippet:
public class HelloServlet extends HttpServlet {
Search WWH ::

Custom Search