Miles to go …

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.fire(new 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:

package com.example.events;
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;
@Qualifier
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
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() {    shortPrint.fire(new PrintEvent(5));    mediumPrint.fire(new PrintEvent(30));    longPrint.fire(new 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;shortPrint.fire(new PrintEvent(5));

can be replaced with

@Inject Event printEvent;
printEvent.select(new 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

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