Miles to go …

October 6, 2010

TOTD #145: CDI Events – a light-weight producer/consumer in Java EE 6

Filed under: General — arungupta @ 5:00 am

Contexts & Dependency Injection (JSR 299) defines a standards-based type-safe Dependency Injection mechanism in the Java EE 6 platform. The type-safety comes from the fact that no String-based identifiers are used to identify the dependencies and instead all the information is specified using the Java object model. The loose coupling is possible because the bean requesting injection need not be aware of the lifecycle, concrete implementation, threading model and similar details of the injected bean. The CDI runtime automatically figures out the right bean in the right scope and context and then injects it correctly for the requestor.

CDI Events take loose coupling to the next level by following the Observer pattern. Event producers raise events that are consumed by observers. The event object carries state from producer to consumer.

Code is king, so lets understand the above text with a simple sample. Consider the following POJO that captures the state showing how many pages have been printed:

public class PrintEvent {
private int pages;
public PrintEvent(int pages) {
this.pages = pages;
public int getPages() {
return pages;

A producer of this event will look like:

@Inject Event printEvent;
public void print() { PrintEvent(5));

Inject a "PrintEvent" using @Inject and "fire" the event with the payload and state. And the consumer of this event will look like:

public void onPrint(@Observes PrintEvent event) {
System.out.println(event.getPages() + " pages printed");

Any method with "@Observes" and the observed event type as parameter will receive the event. In this case, this method will observe all the events. However the observer can specify qualifiers to narrow the set of event notifications received. So lets create a CDI qualifier as:

import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import javax.inject.Qualifier;
public @interface ShortPrintJob {

and create two more similar qualifiers as "MediumPrintJob" and "LongPrintJob". The "producer" can then look like:

@Inject @ShortPrintJob Event shortPrint;@Inject @MediumPrintJob Event mediumPrint;@Inject @LongPrintJob Event longPrint;

public void print2() { PrintEvent(5)); PrintEvent(30)); PrintEvent(80));}

The consumer can then look like:

public void onShortPrint(@Observes @ShortPrintJob PrintEvent event) {    System.out.println(event.getPages() + " pages printed (short)");}

public void onMediumPrint(@Observes @MediumPrintJob PrintEvent event) {    System.out.println(event.getPages() + " pages printed (medium)");}

public void onLongPrint(@Observes @LongPrintJob PrintEvent event) {    System.out.println(event.getPages() + " pages printed (long)");}

Notice how qualifiers are specified in each method to narrow the set of event notifications. This will print the output as:

INFO: 5 pages printed (short)INFO: 30 pages printed (medium)INFO: 80 pages printed (long)

In the above case, "producer" is "qualified" by annotating at the Event inject point. CDI also allows for the qualifiers to be dynamically specified. So

@Inject @ShortPrintJob Event shortPrint; PrintEvent(5));

can be replaced with

@Inject Event printEvent; AnnotationLiteral<ShortPrintJob>(){}).fire(new PrintEvent(10));

Now, if we kept our original method "onPrint" in the consumer as well then each fired event will be delivered to this common method and the "qualified" method.

CDI also defines "Transactional observer methods" that receive event notifications during the different phases of a transaction in which the event was fired. There are pre-defined phases IN_PROGRESS, BEFORE_COMPLETION, AFTER_COMPLETION, AFTER_FAILURE, and AFTER_SUCCESS that allows you to receive and track events and take actions, if any, based upon the result. One use case is to keep the cache updated after receiving events when products are added / deleted from the database. Another use case is to it push data to the front end after a long-running transaction is successful.

You can certainly try all of this in GlassFish and NetBeans provides extensive tooling around CDI and broader Java EE 6. Check out screencast #30 for the complete Java EE 6 tooling using NetBeans.

How are you using CDI events ?

Technorati: totd javaee6 cdi events producer consumer glassfish netbeans

Share and Enjoy:
  • Print
  • Digg
  • Sphinn
  • Facebook
  • Google Bookmarks
  • DZone
  • StumbleUpon
  • Technorati
  • Twitter
  • Slashdot
Related posts:
  1. TOTD #151: Transactional Interceptors using CDI – Extensible Java EE 6
  2. TOTD #144: CDI @Produces for container-managed @Resource
  3. TOTD #134: Interceptors 1.1 in Java EE 6 – What and How ?
  4. TOTD #137: Asynchronous EJB, a light-weight JMS solution – Feature-rich Java EE 6
  5. TOTD #123: f:ajax, Bean Validation for JSF, CDI for JSF and JPA 2.0 Criteria API – all in one Java EE 6 sample application


  1. I’m likin’ CDI, but have a couple of questions:

    1. Maybe it’s a bug, but in Glassfish if I add a qualifier to an inject statement like this:

    @Inject @Hot MyBean bean,

    if I don’t have a producer with the qualifer, then the default is used… That’s cool. BUT, if I have a Qualified Decorator, and an unqualified producer, my decorator is ignored… Is this a bug or the way it should behave?

    2. Can EE 7 please unify Managed Beans and EJB, please? There’s no real need for both @RequestScoped Managed Beans, and @Stateless EJBs (and the same is true for @Singletons/@ApplicationScoped, and @Stateful/@Session) If I need pooling and/or transactional support, let me specify that….

    3. Why aren’t JPA Entities considered managed beans? I really need to be able to Inject into them to be able to make my Entities real, robust domain objects (State + Behavior).

    Comment by Bob — October 6, 2010 @ 10:01 pm

  2. FYI: in NetBeans 6.10 Milestone 2 we’ve enhanced "Inspect CDI" action to better support CDI Events. Try Inspect CDI action on an event declaration and you will get list of observer methods and vice versa: on an event observer method you can inspect list of event declarations which are being observed by that method. Have fun and let us know if something else is desirable. David

    Comment by David — October 7, 2010 @ 6:21 pm

  3. Thanks David, I’ll try this with NetBeans 7 M2 and then blog about it.

    Comment by Arun Gupta — October 12, 2010 @ 9:59 am

  4. Looks horrible.

    If you want to use a lightweight producer/consumer using a standard java.util.concurrent.BlockingQueue imho is my preferred solution. No need to use this horrible code.

    Comment by Peter Veentjer — October 15, 2010 @ 10:43 pm

  5. The artice describes the interface of a publish/subscribe event registry. Producer/consumer refers to a queue that blocks the consumer thread when the queue is empty. Nevertheless, nice article. Is there any standalone implementation or am I forced to go with Glassfish if I want this :-) ?

    Cheers, Oliver

    Comment by Oliver — October 19, 2010 @ 7:18 am

  6. Oliver,

    You can download standalone Weld from

    Comment by Arun Gupta — October 21, 2010 @ 9:10 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
Powered by WordPress