CDI and I

In diesem Post werden ich meine ersten Erfahrungen mit CDI festhalten. Und diese somit den Lesern meines Blogs weitergeben (falls es Leser meines Blogs gibt ;-) ).

1) Meine Entwicklungsumgebung
Als IDE verwende ich Eclipse Indigo mit dem Glassfish v3.0.1 Plugin (und somit Glassfish als AppServer). Anfänglich wollte ich Netbeans verwenden, ich komme damit aber einfach nicht mehr zurecht bzw. gefällt mir Eclipse besser (vor ein paar Jahren wollte ich von Eclipse nix wissen, irgendwie hat sich das nun geändert). PostgreSQL ist die DB meiner Wahl. Um Applikationen auch übers Internet zur Verfügung stellen zu können hab ich mich bei Jelastic registriert.

2) Grundlagen
Beans (für den CDI Container ist so ziemlich alles was injiziert werden kann eine Bean) die vom Container verwaltet werden, müssen alle lokal deployed sein. Weiters muss eine Datei beans.xml (diese kann komplett leer sein) im META-INF bei JAR-Files vorhanden sein bzw. im WEB-INF bei Webprojekten, falls das Projekt vom AppServer nach CDI Managed Beans durchsucht werden soll.
Um eine Bean zu einer CDI Managed Bean zu machen, muss sie mit der Annotation @Named versehen. Mit der Annotation @Inject können dann alle Objekte die vom Container verwaltet werden in ein anderes Objekt injiziert werden.
CDI Managed Beans "leben" in einem eigenen Context, der vom Entwickler festgelegt werden kann. Beans leben solange, wie der Context in dem sie sich befinden, das zulässt. Der Context in dem sich eine Bean befindet wird mit so genannnten Scopes per Annotation angegeben (falls kein Scope angegeben wird, befindet sich die Bean im Dependent Scope, dh die Bean ist vom Scope der Bean in die sie injiziert wird abhängig). Folgende Scopes kennt CDI (nicht zu verwechseln mit den Scopes von JSF!):
  - RequestScoped
  - ConversationScoped
  - SessionScoped
  - ApplicationScoped

Ich denke die Namen erklären bereits wie lange eine Bean lebt. Eine Besonderheit ist der ConversationScope, bei diesem Scope kann der Entwickler im Programmcode angeben wie lange eine Bean lebt (die aktuelle Conversation kann in die Bean injiziert werden, mit den Methoden begin und end kann Einfluss auf die Lebzeit des Scope genommen werden). Somit ist es zB auch möglich unterschiedliche Conversations für unterschiedliche Browsertabs anzulegen. Standardmäßig hat der ConversationScope die gleiche Lebensdauer wie ein RequestScope.

CDI ist nicht transaktionssicher, dazu werden immer noch EJBs benötigt. Diese können aber auch mit @Named annotiert und an einen Scope gebunden werden.

JPA Entities können nicht vom CDI Container verwaltet werden.

3) Wozu CDI?
CDI verbindet die Darstellung von Daten (JSF) mit der Businesslogik und deren LifeCycle nahtlos. Dank der verschiedenen Scopes befindet sich immer nur wirklich das was benötigt wird in der Session, somit wird diese Schlank gehalten.
Weiters bietet CDI typsichere Injection und dennoch eine lose Kopplung der einzelnen Programmmodule.
Das Eventsystem von CDI ist nur ein weiteres Beispiel wie elegant CDI typsichere Injection und loose Kopplung zur Verfügung stellt.

4) Was halte ich davon?
Man kann es wahrscheinlich zwischen den Zeilen lesen, das ich begeistert bin. Noch nie war es mit JavaEE möglich so schnell bzw mit so einer Leichtigkeit an sein Ziel zu kommen. Die Tage des "schwergewichtigen" J2EE sind endlich vorbei.
Der König ist tot, lang lebe der König ;-)

Folgender Post gibt Aufschluss über die verschiedenen Beantypen:

http://www.andygibson.net/blog/article/comparing-jsf-beans-cdi-beans-and-ejbs/