CDI, JSF & Dependency Injection in Java EE 6 - By Reza Rahman


News: CDI, JSF & Dependency Injection in Java EE 6 - By Reza Rahman

  1. Dependency Injection in Java EE 6 - Part 5

    This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection as well as robust context management for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.

    In the previous articles in the series, we discussed basic dependency injection, scoping, producers/disposers, component naming, interceptors, decorators, stereotypes, events and conversations. In this article we will discuss CDI’s interaction with JSF in detail. In the next and last article of this series, we will cover portable extensions, available implementations as well as CDI alignment with Seam, Spring and Guice. We will augment the discussion with a few implementation details using CanDI, Caucho’s independent implementation of JSR 299 included in the open source Resin application server.
    Dependency Injection in Java EE 6 - Part 5

    Previous Articles in this Thread:

    Dependency Injection in Java EE 6: Part I
    Dependency Injection in Java EE 6: Part II
    Dependency Injection in Java EE 6: Part III 
    Dependency Injection in Java EE 6: Part IIII 

    Books on EJB 3 and EJB 3.1 Development

    EJB 3 in Action by Reza Rahman
    Enterprise JavaBeans 3.1 ~ Andrew Lee Rubinger
    Beginning EJB 3 Application Development ~ Raghu R. Kodali
    Pro EJB 3: Java Persistence API ~ Mike Keith

    Threaded Messages (3)

  2. You might be interested in another CDI tutorial at IBM developerWorks as well.


  3. POJO DI[ Go to top ]

    Reza, maybe you can clarify something for me, since you mentioned comments on support for Struts 2 in Resin.

    Simply, if you have a generic POJO and wish to use the DI features of JEE 6, is that possible?

    For example, in JEE 5, all of the injection features only worked on container managed objects, notably Servlets and Session Beans.

    Is there any facility in JEE 6 to expose the injection at a standard, API level so that POJO, "non-managed" classes can take advantage of the DI infrastructure? Currently, JEE 5, POJOs fall back on to JNDI for these features.

    It sounds from your comment about Struts 2 that you expect to make container changes to support Struts 2, or were you suggesting just adding a convenience layer or Struts 2 extensions (however that is done, not being well familiar with Struts 2) to support DI?


  4. POJO DI[ Go to top ]


    I know it's been a little while since I started the series, but you should really re-read the first article in the series. One of the core goals of CDI is to be able to manage any Java object as transparently as possible. In that vein, you can @Inject a Java object that has absolutely no Java EE annotations on it (such as a Struts 2 action class or even further, just a random Java object that is not part of any framework or infrastructure at all). We've taken that a step further in Resin and allow you to annotate these arbitrary Java objects with EJB service level annotations (for transactions, security, pooling, remoting, etc) and inject/manage them via CDI. That's basically the model we hope to standardize in Java EE 7.

    In case of Struts 2 specifically, it's mostly just a matter of making CDI an object factory for Struts 2 and inserting ourselves into the Struts 2 life-cycle so we can inject into action classes, etc pretty much in the same way that existing DI frameworks that support Struts 2 do...