Rookie – praktische Einführung

Standardmäßig liefert CDI vier Built-in Qualifiers, die auch in Kombination mit eigenen Qualifiern verwendet werden können (Tabelle 1).

Bean-Namen

Mit dem @javax.inject.Named Qualifier kann ein spezifischer Name für eine Bean festgelegt werden, der für EL-Zugriffe verwendet werden kann. Ein Beispiel dafür ist der Zugriff über JSF Views. Die Bean kann durch @Named einen sprechenden Namen erhalten, der wiederum in der JSF View verwendet wird.

Listing 9.1: Bean-Namen definieren

@Named("nachrichtenBean")
public class MessagingServiceBean {
  public String getMessage() {
    return "Hello World";
  }
}

Listing 9.2: EL-Ausdruck mit Bean-Namen in der UI-Schicht verwenden

Die Nachricht lautet : #{nachrichtenBean.message}

Beispiel: Alternativen

Alternativen erlauben während des Deployments die Auswahl der Bean-Implementierung. Dazu muss die alternative Bean mit @javax.enterprise.inject.Alternative annotiert sein. Standardmäßig sind diese annotierten Beans nicht aktiviert. Dazu muss ein passender Eintrag mit dem Namen der Bean in der beans.xml gemacht werden, wodurch die bestehende Bean durch die alternative Bean ausgetauscht wird. Das ist sehr hilfreich, wenn für unterschiedliche Deployment-Umgebungen verschiedene Implementierungen verwendet werden sollen. Für eine Integrationsumgebung könnte zum Beispiel eine Stub-Implemtierung einer Bean verwendet werden, um die echte Implementierung zu überschreiben. In unserem Fall würde die Body Bean durch FibreBody ersetzt werden. Der beans.xml-Eintrag sieht dabei wie in Listing 10 aus.

Listing 10.1: EL-Ausdruck mit Bean-Namen in der UI-Schicht verwenden

@Alternative
public class FibreBody extends Body {

}

Listing 10.2: EL-Ausdruck mit Bean-Namen in der UI-Schicht verwenden

de.sample.parts.FibreBody

Alternativen, die eine Bean erweitern wie in unserem Beispiel, sollten noch alle Metadaten erben, z. B. Qualifier und Namen. In diesem Fall muss die Bean mit @javax.enterprise.inject.Specializes annotiert werden. Dadurch wird die Original-Bean komplett durch die alternative Bean ersetzt.

Deployment der CDI-Anwendung

Damit CDI in ihren Java-EE-Anwendungen aktiviert werden kann, müssen die Bean-Klassen in einem Bean-Deployment-Archiv deployt werden. Dazu muss bei JAR-Dateien eine beans.xml in dem META-INF-Ordner der Anwendung angelegt werden. Für WAR-Dateien muss die beans.xml in dem WEB-INF-Ordner angelegt werden. Es reicht aus, eine leere beans.xml anzulegen. Der Java-EE-Container erkennt diese Archive automatisch und lässt den CDI-Container die Beans verwalten. Listing 11 zeigt eine vollständige beans.xml, die Sie für Ihre IDE verwenden können. Ihre IDE sollte automatisch alle möglichen XML Tags vorschlagen, z. B. bei Eclipse IDE durch STRG + LEERTASTE. In der Beans XML können Interceptors, Decorators und Alternativen konfiguriert werden. Mehr Details folgen in einem weiteren Artikel.

Listing 11: beans.xml

Aktuelle Implementierungen

Zusammenfassung

Zusammenfassend kann man sagen, dass CDI viele gute Ideen vereint und die Entwicklung von Enterprise-Anwendungen vereinfacht. CDI bringt viel Leichtgewichtigkeit in die Java-EE-Plattform, muss sich aber erst im Alltag gegen bestehende Dependency-Injection-Frameworks wie Spring, EJB, Guice und Seam durchsetzen. Da es Bestandteil von Java EE 6 geworden ist, sollte sich jeder Entwickler einmal damit auseinander gesetzt haben. Zudem müssen Programmierer sich an den deklarativen Programmieransatz von CDI gewöhnen. Der Einsatz von Qualifiern und eigenen Annotationen ist Anfangs gewöhnungsbedürftig. Das gleiche gilt für die automatische Verwaltung von Beans in den jeweiligen Kontexten.