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

Version 2.0 der CDI Specification auch in Java SE nutzbar

von Lars Röwekamp und Arne Limburg

Arne Limburg, Lars Röwekamp


Bisher ist CDI ein Komponentenframework, das Dependency Injection zur Verfügung stellt, allerdings nur für Java-EE-Anwendungen. Die aktuell gültige Version ist das Maintenance-Release 1.2. Wie wir bereits in der letzten Kolumne berichteten, hat die Spezifizierung von CDI 2.0 aber schon begonnen. Und sie bringt ein durchaus interessantes Feature, mit dem es möglich sein wird, CDI auch außerhalb eines Java-EE-Containers standardisiert zu benutzen. CDI soll in Java SE nutzbar werden. Wir werden in dieser Kolumne vorstellen, wie das API aussehen könnte und was noch fehlt. Möchte man in einem Java-EE-Container Dependency Injection verwenden, so kann man dies bereits seit Java EE 5 out of the box. Dependency Injection war damals allerdings noch frameworkspezifisch. So gibt es spezielle Annotations, um Dependency Injection in EJB zu verwenden (@Resource und @EJB) und andere, um Dependency Injection in JSF zu erhalten (@ ManagedProperty). Erst seit Java EE 6 gibt es mit CDI einen einheitlichen Dependency-Injection-Standard über alle Schichten und Frameworks hinweg. Jedoch ist CDI bisher nur in Java EE verfügbar. Sobald man sich in einem reinen Servlet-Container oder gar einer Swing- oder JavaFX-Anwendung befindet, muss man entweder auf CDI verzichten oder auf implementierungsspezifische APIs zurückgreifen. Das soll sich mit CDI 2.0 ändern.Dependency Injection in Java SE CDI basiert zwar auf @Inject, hatte bisher aber immer Java EE als Zielplattform. Unabhängig davon haben die CDI-Implementierungen aber auch immer die Möglichkeit, in Java SE zu laufen (Weld SE [4] und OpenWebBeans [5]), dann aber mit einem implementierungsspezifischen API.Eines haben aber alle hier vorgestellten Frameworks gemeinsam: Es gibt bisher keinen standardisierten Weg, sie zu booten. Möchte man also eine CDI-Anwendung starten, muss man auf implementierungsspezifische APIs zurückgreifen. Ein wenig Abhilfe schafft da das Framework DeltaSpike mit CdiCtrl [6]. Hiermit ist es zumindest möglich, Weld und OpenWebBeans mit einem gemeinsamen API zu starten. Möchte man im Projektverlauf also die CDI-Implementierung wechseln, so ändert sich der Startcode nicht.Containerstart mit CDI 2.0Listing 1CDIProvider provider = CDI.getCDIProvider();if (!provider.isInitialized()) { provider.initialize();}CDI.current().select(MyBean.class).get().myMethod();Provider.shutdown();CDIProvider provider = CDI.getCDIProvider();if (!provider.isInitialized()) { provider.initialize();}CDI.current().select(MyBean.cl...

Java Magazin
Kolumne: EnterpriseTales

Version 2.0 der CDI Specification auch in Java SE nutzbar

von Lars Röwekamp und Arne Limburg

Arne Limburg, Lars Röwekamp


Bisher ist CDI ein Komponentenframework, das Dependency Injection zur Verfügung stellt, allerdings nur für Java-EE-Anwendungen. Die aktuell gültige Version ist das Maintenance-Release 1.2. Wie wir bereits in der letzten Kolumne berichteten, hat die Spezifizierung von CDI 2.0 aber schon begonnen. Und sie bringt ein durchaus interessantes Feature, mit dem es möglich sein wird, CDI auch außerhalb eines Java-EE-Containers standardisiert zu benutzen. CDI soll in Java SE nutzbar werden. Wir werden in dieser Kolumne vorstellen, wie das API aussehen könnte und was noch fehlt. Möchte man in einem Java-EE-Container Dependency Injection verwenden, so kann man dies bereits seit Java EE 5 out of the box. Dependency Injection war damals allerdings noch frameworkspezifisch. So gibt es spezielle Annotations, um Dependency Injection in EJB zu verwenden (@Resource und @EJB) und andere, um Dependency Injection in JSF zu erhalten (@ ManagedProperty). Erst seit Java EE 6 gibt es mit CDI einen einheitlichen Dependency-Injection-Standard über alle Schichten und Frameworks hinweg. Jedoch ist CDI bisher nur in Java EE verfügbar. Sobald man sich in einem reinen Servlet-Container oder gar einer Swing- oder JavaFX-Anwendung befindet, muss man entweder auf CDI verzichten oder auf implementierungsspezifische APIs zurückgreifen. Das soll sich mit CDI 2.0 ändern.Dependency Injection in Java SE CDI basiert zwar auf @Inject, hatte bisher aber immer Java EE als Zielplattform. Unabhängig davon haben die CDI-Implementierungen aber auch immer die Möglichkeit, in Java SE zu laufen (Weld SE [4] und OpenWebBeans [5]), dann aber mit einem implementierungsspezifischen API.Eines haben aber alle hier vorgestellten Frameworks gemeinsam: Es gibt bisher keinen standardisierten Weg, sie zu booten. Möchte man also eine CDI-Anwendung starten, muss man auf implementierungsspezifische APIs zurückgreifen. Ein wenig Abhilfe schafft da das Framework DeltaSpike mit CdiCtrl [6]. Hiermit ist es zumindest möglich, Weld und OpenWebBeans mit einem gemeinsamen API zu starten. Möchte man im Projektverlauf also die CDI-Implementierung wechseln, so ändert sich der Startcode nicht.Containerstart mit CDI 2.0Listing 1CDIProvider provider = CDI.getCDIProvider();if (!provider.isInitialized()) { provider.initialize();}CDI.current().select(MyBean.class).get().myMethod();Provider.shutdown();CDIProvider provider = CDI.getCDIProvider();if (!provider.isInitialized()) { provider.initialize();}CDI.current().select(MyBean.cl...

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