© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Asynchrone Events in CDI 2.0

CDI ist seit der Version 1.0 in Java EE 6 der neue Enterprise-Komponentenstandard. Während es mit CDI 1.1 in Java EE 7 nur ein Minor-Update gab, kann für Java EE 8 wieder mit einem größeren Entwicklungsschritt gerechnet werden. Die Spezifizierung von CDI 2.0 hat bereits begonnen. Eines der Themen, die auf der Agenda stehen, ist die asynchrone Verarbeitung von Events. Wir werfen in dieser Kolumne einen Blick auf den aktuellen Stand der Spezifikation und geben einen Ausblick darauf, was für Möglichkeiten asynchrone Events bieten.

Arne Limburg, Lars Röwekamp


Der CDI-Eventing-Mechanismus bietet bereits seit CDI 1.0 eine einfache Möglichkeit, das Observer-Pattern zu implementieren und Java-EE-Architekturen zu entkoppeln. Um ein CDI-Event abzufeuern, genügt es dabei, sich das Containerobjekt vom Typ Event injizieren zu lassen und darauf die Methode fire(...) aufzurufen. Der Payload (das Eventobjekt, das tatsächlich verschickt wird) kann dabei ein beliebiges Java-Objekt sein. Möchte eine CDI Bean auf ein solches Event reagieren, muss sie nur eine beliebige Methode zur Verfügung stellen, die über einen Parameter vom Typ des Eventobjekts (oder einer Oberklasse) verfügt, und diesen mit @ Observes annotieren (Listing 1).Wie überall in CDI, funktioniert auch hier das Einschränken über Qualifier. Versieht man den Injection Point für das Event mit Qualifiern, so reagieren auch nur Observer auf das Event, deren @Observes-Parameter mit denselben Qualifiern (oder einem Subset davon) ausgestattet ist. Eventtyp und Qualifier können auch über die Methode select(...) am Eventobjekt weiter eingeschränkt werden. Über Einstellungen an der Observer-Methode können weitere Einschränkungen vorgenommen werden. So kann zum Beispiel festgelegt werden, dass der Observer nur aufgerufen wird, wenn die zugehörige Bean schon existiert (über das @ Observes-Attribut notifyObserver), oder es kann festgelegt werden, in welcher Transaktionsphase der Observer aufgerufen werden soll (über das Attribut during). Observer, die hier eine andere Phase als IN_PROGRESS angeben, werden Transactional Observer genannt.Ab CDI 2.0 wird es über @Priority wahrscheinlich möglich sein, Observer zu priorisieren und so eine Reihenfolge der Event-Observer festzulegen [1]. Auch wenn über die Angabe einer Transaktionsphase das Ausführen des Observers verzögert werden kann (nämlich bis zum Transaktions-Commit), läuft die gesamte Eventverwaltung bisher synchron, d. h. die Observer werden in dem Thread aufgerufen, in dem das Event gefeuert wird. Das soll sich nun mit CDI 2.0 ändern. Listing 1public class EventLauncher { @Inject private Event event;  public void fireMyEvent() { event.fire(new MyEventPayload()); }} public class MyEventObserver { public void listenToMyEventPayload(@Observes MyEventPayload payload) { // do something }}public class EventLauncher { @Inject private Event event;  public void fireMyEvent() { event.fire(new MyEventPayload()); }} public class MyEventObserver { pu...

Java Magazin
Kolumne: EnterpriseTales

Asynchrone Events in CDI 2.0

CDI ist seit der Version 1.0 in Java EE 6 der neue Enterprise-Komponentenstandard. Während es mit CDI 1.1 in Java EE 7 nur ein Minor-Update gab, kann für Java EE 8 wieder mit einem größeren Entwicklungsschritt gerechnet werden. Die Spezifizierung von CDI 2.0 hat bereits begonnen. Eines der Themen, die auf der Agenda stehen, ist die asynchrone Verarbeitung von Events. Wir werfen in dieser Kolumne einen Blick auf den aktuellen Stand der Spezifikation und geben einen Ausblick darauf, was für Möglichkeiten asynchrone Events bieten.

Arne Limburg, Lars Röwekamp


Der CDI-Eventing-Mechanismus bietet bereits seit CDI 1.0 eine einfache Möglichkeit, das Observer-Pattern zu implementieren und Java-EE-Architekturen zu entkoppeln. Um ein CDI-Event abzufeuern, genügt es dabei, sich das Containerobjekt vom Typ Event injizieren zu lassen und darauf die Methode fire(...) aufzurufen. Der Payload (das Eventobjekt, das tatsächlich verschickt wird) kann dabei ein beliebiges Java-Objekt sein. Möchte eine CDI Bean auf ein solches Event reagieren, muss sie nur eine beliebige Methode zur Verfügung stellen, die über einen Parameter vom Typ des Eventobjekts (oder einer Oberklasse) verfügt, und diesen mit @ Observes annotieren (Listing 1).Wie überall in CDI, funktioniert auch hier das Einschränken über Qualifier. Versieht man den Injection Point für das Event mit Qualifiern, so reagieren auch nur Observer auf das Event, deren @Observes-Parameter mit denselben Qualifiern (oder einem Subset davon) ausgestattet ist. Eventtyp und Qualifier können auch über die Methode select(...) am Eventobjekt weiter eingeschränkt werden. Über Einstellungen an der Observer-Methode können weitere Einschränkungen vorgenommen werden. So kann zum Beispiel festgelegt werden, dass der Observer nur aufgerufen wird, wenn die zugehörige Bean schon existiert (über das @ Observes-Attribut notifyObserver), oder es kann festgelegt werden, in welcher Transaktionsphase der Observer aufgerufen werden soll (über das Attribut during). Observer, die hier eine andere Phase als IN_PROGRESS angeben, werden Transactional Observer genannt.Ab CDI 2.0 wird es über @Priority wahrscheinlich möglich sein, Observer zu priorisieren und so eine Reihenfolge der Event-Observer festzulegen [1]. Auch wenn über die Angabe einer Transaktionsphase das Ausführen des Observers verzögert werden kann (nämlich bis zum Transaktions-Commit), läuft die gesamte Eventverwaltung bisher synchron, d. h. die Observer werden in dem Thread aufgerufen, in dem das Event gefeuert wird. Das soll sich nun mit CDI 2.0 ändern. Listing 1public class EventLauncher { @Inject private Event event;  public void fireMyEvent() { event.fire(new MyEventPayload()); }} public class MyEventObserver { public void listenToMyEventPayload(@Observes MyEventPayload payload) { // do something }}public class EventLauncher { @Inject private Event event;  public void fireMyEvent() { event.fire(new MyEventPayload()); }} public class MyEventObserver { pu...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang