Wer also ein Tippspiel zur WM oder zur Bundesliga mit Freunden oder Arbeitskollegen veranstalten möchte kann sich auf 11tipper.de eines einrichten.
Wer mehr über das Tippspiel an sich wissen möchte sollte den Artikel auf webthreads.de lesen oder sich die Features auf 11 Tipper direkt ansehen. Es bestehen auch zwei Demo Tipprunden in denen man als Spielleiter oder Tipper herumklicken kann.

Verwendete Frameworks

Jetzt noch ein paar Worte zur Technik. Das Tippspiel wird mit JSF 1.2 und JBoss Seam 2.2.0 entwickelt. Viele kennen JBoss Seam nur auf einem Application Server wie eben den JBoss AS. Ich habe Seam auf einem Tomcat 6 ohne Embedded JBoss verwendet. Es wird somit anstatt auf EJBs voll auf POJOs gesetzt und auch nicht so getan als wäre mann auf einem Application Server. Die Persistenz ist mit JPA (Hibernate) umgesetzt. Seam verwendet zur Validierung der Eingaben an der Oberfläche die JPA Annotationen an den Entities. Für Timer und zeitliche Verzögerungen wird Quarz verwendet. Das Frontend ist mit Facelets und JBoss RichFaces 3.3 umgesetzt. Verfeinert wird das Ganze mit viel Ajax und jQuery 1.4 als JavaScript Bibliothek.

In der Vergangenheit sind schon ein paar Artikel aus den Erkenntnissen dieses Projekts hier auf javathreads.de veröffentlicht worden. Und ich werde wohl noch das ein oder andere Tutorial dazu hier in naher Zukunft veröffentlichen. Falls jemand eine bestimmte Frage zur Umsetzung hat dann nur raus damit ich antworte garantiert =).

Wer eine größere Version sehen oder herunterladen möchte sollte sich diese direkt auf flickr.com ansehen.

Im Folgenden soll gezeigt werden wie der einfachste Einstieg mit Hilfe des Seam JPA Beispiels gelingt um ein Seam Projekt inklusive JPA Persistenz durch Hibernate auf Tomcat Basis in Eclipse erstellen kann. In diesem Tutorial wird in erster Linie nicht auf die einzelnen Konfigurationsdateien eingegangen, das wird in einem extra Artikel gemacht, sondern lediglich auf das Ziel hingearbeitet ein Seam Projekt in Eclipse zu erstellen und auf den Tomcat laufen zu lassen. Es bestehen zwei Möglichkeiten Seam auf dem Tomcat laufen zu lassen. Zum Einen die Verwendung eines JEE Microcontainer mit JBoss Embedded und zum anderen gänzlich ohne JEE Microcontainer. In diesem Tutorial wird kein JEE Mircrocontainer verwendet.

Vorbereitungen

Verwendete Tools und Versionen

• Eclipse Gallileo (3.5) – IDE for Java EE Developers
• Apache Tomcat Version 6.0.20
• JBoss Seam Version 2.2.0
• JBoss Tools Version 3.1.0
• MySQL Version 5.0.x (oder DB der Wahl)

Es wird in diesem Tutorial nicht auf das Herunterladen der Software und Tools, der Verzeichnisstruktur und Eclipse sowie die Konfiguration von MySQL eingegangen. Benötigt man eine genaue Anleitung für diese Punkte sollte man sich das äquivalente Tutorial “Tutorial: Mit JBoss Seam und JEE5 unter Eclipse starten” genauer ansehen. Diese Punkte verhalten sich aktuell immer noch gleich bis auf die Verwendung des JBoss AS der jetzt durch den Apache Tomcat ausgetauscht wird.

Es wird also ein Eclipse JEE Bundle (WTP inklusive), ein entpackter/installierter Tomcat 6 und eine vorhandene Datenbank vorausgesetzt.

Tomcat Server Runtime in Eclipse konfigurieren

Weil das Seam Projekt direkt aus Eclipse heraus in den Tomcat deployt und gestartet werden soll muss als erstes der Tomcat als Server Runtime installiert werden. Dazu im Hauptmenü unter Window->Preferences->Server->Runtime Environment den Button “Add” klicken.

Anschließend Apache Tomcat v6.0 und weiter unten “Create a new local server” auswählen und den Button “Next” klicken:

Auf dem letzten Dialog den Tomcat Installationspfad angeben. Ich verwende für meine Projekte immer den Tomcat den man einfach als ZIP herunterladen und anschließend an einer bestimmten Stelle entpacken kann. Den letzten Dialog des Wizzards mit dem Button “Finish” beenden:

Der Tomcat sollte nun in Eclipse konfiguriert sein:

Die Preferences verlassen und die Server View “Hauptmenü->Windows->Show View->Servers” öffnen. Es sollte der eben konfigurierte Tomcat, sofern das Häkchen bei “Create a new local server” gesetzt wurde, zu sehen sein:

Der Server sollte sich auch ohne Probleme starten lassen:

Vom Prinzip ist das Einrichten einer Server Runtime nichts neues aber ich wollte die Schritte wenigstens einmal kurz zeigen =).

Seam JPA Beispiel für Tomcat bauen und testen

JPA Beispiel mit ANT für Tomcat 6 bauen

Die wohl schnellste Variante ein Seam Projekt inklusive Persistierung via JPA für Tomcat als Eclipse Projekt zu erstellen ist das Importieren des mit vom Seam ausgelieferten JPA Beispiels. Seam liefert eine beachtliche Menge an Beispielen aus, welche alle gebaut und deployt werden können. Darunter befindet sich eben auch das JPA Beispiel welches im entpackten Seam Verzeichnis unter examples/jpa liegt und man für Tomcat 5 und Tomcat 6 bauen lassen kann.

Um sich ein WAR File für Tomcat 6 zu erstellen muss zum einen ANT im Pfad (Umgebungsvariable PATH) konfiguriert sein und zum anderen die Umgebungsvariable JAVA_HOME auf ein JDK 6 zeigen. Ist beides konfiguriert die Eingabeaufforderung im Seam examples Ordner öffnen. An dieser Stelle in kleiner Tipp für alle Windows Vista Benutzer: hält man die Schift-Taste gedrückt und öffnet das Kontextmenü auf einem Ordner so erscheint eine zusätzliche Auswahl “Eingabeaufforderung hier öffnen”:

Alle anderen müssen sich durchhangeln ;). Hat man die Eingabeaufforderung im gewünschten Order kann man noch einmal die beiden notwendigen Umgebungsvariablen PATH und JAVA_HOME überprüfen und anschließend den build für Tomcat 6 mit “ant tomcat6” gestartet werden:

D:\Projekte\JBossSeamTomcat\jboss-seam-2.2.0.GA\examples\jpa>echo %PATH%
C:\Windows\system32;...;D:\Development\apache-ant-1.7.1/bin

D:\Projekte\JBossSeamTomcat\jboss-seam-2.2.0.GA\examples\jpa>echo %JAVA_HOME%
D:\Projekte\JBossSeamTomcat\jdk-1.6

D:\Projekte\JBossSeamTomcat\jboss-seam-2.2.0.GA\examples\jpa>ant tomcat6
Buildfile: build.xml
...
init:
     [echo] Building The JPA Example for plain Tomcat 6.0 2.2
...
noejb.archive:
      [jar] Building jar: D:\Projekte\JBossSeamTomcat\jboss-seam-2.2.0.GA\examples\jpa\dist-tomcat6\jboss-seam-jpa.war

BUILD SUCCESSFUL
Total time: 4 seconds

Die interessante Zeile ist die letzte, denn da steht dass die jboss-seam-jpa.war Datei im Ordner “..\examples\jpa\dis-tomcat6\” abgelegt wurde.

JPA WAR im Tomcat testen

Die einfachste Variante zu testen ob das erzeugte war erst einmal überhaupt funktioniert ist ein Test direkt im Tomcat. Dazu die WAR Datei jboss-seam-jpa.war kopieren und im Tomcat Verzeichnis in den Unterorder “webapps” kopieren:

Startet man anschließend den Tomcat (<TomcatDir>/bin/startup.bat) erscheint sehr wahrscheinlich die Fehlermeldung, dass der HSQL DB Treiber "" nicht gefunden wurde:

20:34:06,520 INFO  [DatasourceConnectionProvider] Using datasource: java:comp/env/jdbc/TestDB
20:34:06,522 WARN  [SettingsFactory] Could not obtain connection metadata
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver class 'org.hsqldb.jdbcDriver'
        at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1136)
        ...
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: java.lang.ClassNotFoundException: org.hsqldb.jdbcDriver
...
27.09.2009 20:34:06 com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Mojarra (1.2_12-b01-FCS) for context '/jboss-seam-jpa'
27.09.2009 20:34:07 org.apache.catalina.core.StandardContext start
SCHWERWIEGEND: Error listenerStart

Dazu muss man wissen, dass das Seam JPA Beispiel intern mit einer HSQL DB arbeitet und den Treiber im Tomcat lib Verzeichnis voraussetzt. Am Einfachsten ist es wenn der HSQL DB Treiber von Sourceforge heruntergeladen wird. Zum aktuellen Zeitpunkt ist die Version 1.8.1 (Direktlink) die aktuellste. Das herunterladene Zip entpacken und aus dem Unterordner lib das hsqld.jar kopieren und im Tomcat lib Verzeichnis einfügen. Anschließend den Tomcat neu starten - dieser sollte nun ohne Fehler neu starten:

27.09.2009 20:42:17 com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Mojarra (1.2_12-b01-FCS) for context '/jboss-seam-jpa'
...
27.09.2009 20:42:19 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
27.09.2009 20:42:19 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
27.09.2009 20:42:19 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/13  config=null
27.09.2009 20:42:19 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4348 ms

Nun kann die JPA Beispielanwendung mit der URL http://localhost:8080/jboss-seam-jpa aufgerufen werden:

Der Deploymenttest hat gezeigt, dass sich das erstellte WAR ohne Probleme im Tomcat deployen und aufrufen lässt.

Eclipse Projekt erstellen

Projekt durch WAR Import erstellen

Als letzten Schritt fehlt nur noch der Import des WARs als Eclipse Projekt.
Dazu den eben gestarteten Tomcat wieder stoppen und das jboss-seam-jpa.war wieder aus dem webapps Verzeichnis entfernen. In Eclipse den Import Dialog öffnen: "Hauptmenü->File->Import->Web->WAR file" und den zu importierenden Typ WAR wählen:

Button "Next" drücken. Im folgenden Dialog muss das zu importierende WAR File im Filesystem selektiert werden. Im "Browse" Dialog zu dem Seam examples/jpa/dist/tomcat6 Verzeichnis wechseln und das jboss-seam-jpa.war auswählen. Der Web Projekt Name wird automatisch gewählt und sollte erst einmal so gelassen werden. Die Target Server Runtime "Apache Tomcat v6" wurde schon in den Vorbereitungen konfiguriert, so dass dieser auch automatisch vorausgewählt wird. Ist keine Server Runtime verfügbar sollte sie spätestens jetzt konfiguriert werden.

Man kann den Dialog eigentlich schon mit dem Button "Finish" beenden. Falls man doch noch mit "Next" weitergeht dann in dem nächsten Dialog kein JAR selektieren und spätestens dann mit dem Button "Finish" den Import Wizzard beenden und den eigentlichen Import starten:

Den Dialog mit dem Button "Finish" beenden. Anschließend wird das Eclipse Projekt erstellt und erscheint im Package Explorer wie folgt:

Projekt aus Eclispe heraus im Tomcat deployen

Nun kommt der letzte entscheidende Test ob sich dieses importierte Projekt auch aus Eclipse heraus deployen und aufrufen lässt. Dazu in der Server View dem Tomcat Server das Projekt zum deployen hinzufügen: rechte Maustaste auf den Server->Add and Remove...->"jboss-seam-jpa" Projekt mit Doppelklick hinzufügen:

Mit dem Button "Finish" den Dialog verlassen und den Tomcat Server aus Eclipse heraus starten. In der Console View darf, wie auch vorhin in der Eingabeaufforderung, keine Exception zu sehen sein:

Der letzte Test ist natürlich wieder der Aufruf der Webanwendung im Browser unter der URL "http://localhost:8080/jboss-seam-jpa". Und weil wir uns ja gerade so schön in Eclipse bewegen machen wir dies auch direkt im Eclipse eingebetteten Browser. Diesen findet man in der Toolbar als Weltkugel oder über das Hauptmenü->Window->Show View->Other...->General->Internal Web Browser.

Auch das hat ohne weiter Probleme funktioniert und nun steht dem erkunden und erweitern des Projekts nichts mehr im Wege.

Ausblick

In diesem Tutorial wurde nicht auf das Projekt selbst und auf die verschiedenen Dateien für die Konfiguration eingegangen. Das ist nochmal ein eigener Artikel in der nahen Zukunft der beschreiben wird wie man ein Seam Projekt für den Tomcat in Eclipse aufsetzt wenn man die Schritte der Konfiguration alle von Hand selbst macht bzw. den Seam Projekt Wizzard verwendet.

Mit diesem Tutorial sollte gezeigt werden wie man relativ einfach an eine funktionierendes Projekt für ersten Start mit Seam und JPA unter Tomcat haben kann. Wer sich schon besser mit den einzelnen Frameworks (JPA, Seam, Facelets, JSF, RichFaces, ...) auskennt wird auch einigermaßen schnell die Struktur durchblicken und loslegen können. Ansonsten eignet sich dieses Projekt auch sehr gut um einfach mal herumzuprobieren und die verschiedenen Technologien kennenzulernen. Auch Tests an den Konfigurationen kann man hier einfach machen denn wer das WAR erst einmal hat und den Import Dialog kennt kann sich das funktionierende Projekt in wenigen Sekunden wiederherstellen.

Viel Spaß beim ausprobieren!

So könnte z.B. die Entity Bean “User” wie folgt aussehen:

@Entity
public class User {

  @Id
  private Long id;

  @Length(min = 5, max = 50)
  @Pattern(regex="[a-zA-Z0-9]+")
  @NotNull
  private String name;

  @Email
  @NotNull
  private String email;

  @Past
  private Date birthday;

  // Getter & Setter
}

Der Hibernate Validator arbeitet auf zwei Ebenen mit den Constraints. Zum einen die für Anwendungen sehr hilfreiche Funktion des “In-Memory-Checks” für Instanzen. In diesem Fall wird noch vor der eigentlichen Datenbank Operation gegen die konfigurierten Constraints geprüft. Zum anderen können ein paar Hibernate Constraints direkt in das Datenbankschema übernommen und somit noch einmal von der Datenbank selbst geprüft werden.

Im folgenden noch die Tabelle aller vordefinierten Hibernate Validation Annotationen:

Mit diesem Set an Hibernate Annotationen dürfte man die normalen und häufigsten Anforderungen an die Validierung erfüllt werden. Das mächtigste Constraint dürfte die @Pattern(regex="") sein, die man mit regulären Ausdrücken befüllen kann.

Als letzte Information in diesem Artikel noch der Hinweis, dass für jede Hibernate Annotation ein Standardfehlertext existiert, der aber angepasst werden kann. So kann jede gesetzte Annotation mit einer eigenen Fehlermeldung versehen werden. Dafür dient das Attribut message und wird in der Exception oder dem InvalidValue Objekt bei einer Constraint Verletzung gesetzt. Hier noch ein Beispiel für das Verwenden von Nachrichten:

  @Length(min = 5, max = 50, message="Username muss zwischen 5 und 50 Zeichen lang sein")
  private String name;

  @Past(message="Der Geburtstag muss in der Vergangenheit liegen")
  private Date birthday;

Natürlich kann auch internationalisiert werden. Dazu einfach eine ValidatorMessages.properties bzw. ValidatorMessages_de.properties erstellen und im Classpath ablegen und die entsprechenden keys anpassen oder eigene erstellen:

Und in der Klassen dann die Keys mit geschweiften Klammern verwenden:

  @Length(min = 5, max = 50, message="{usernameLength}")
  private String name;

  @Past(message="{bdayPast}")
  private Date birthday;

Selbst wenn man die Validierung noch nicht im Frontend eingebaut oder in der Anwendung verwendet lohnt es sich diese in der Entity Bean zu konfigurieren. Neben den direkt im Datenbankschema eingebauten Constraints dient es bei der Entwicklung und Verwendung der Entity Beans absolut der Übersicht und zentralisiert die Vorgaben der Validierung.

(Auf das jeweile Bild klicken um die PDF Datei direkt herunterzuladen)

Im folgenden möchte ich noch kurz einen kleinen Auszug aus den Präsentationen zeigen, denn diese Folien zeigen sehr schön die Kernfunktionalitäten und Features der Web Beans Spezifikation anhand eines kleinen Code Beispiels.

Zukünftig kann jede einfache Java Klasse (POJOs) aber auch Enterprise Java Beans (EJBs) für Dependency Injection verwendet werden um sie in anderen Beans zu verwenden:

Möchte man eine Klasse in einer anderen verwenden kann man sie mit der Annotation @Current injectien. Der Binding Type @Current ist der Standardbinding Type und kann verwendet werden wenn man keinen eigenen festgelegt hat und wenn die Zuordnung zur Klassen eindeutig ist:

Würde man z.B. ein Interface verwenden und dieses zweimal implementieren kann man @Current nicht mehr verwenden sondern muss eigene Binding Types erstellen. In den meißten Fällen arbeitet man allerdings eindeutig, so dass man sich durch diesen Standardbinding Type Arbeit sparen kann.

Die zweite Variante ein Dependency Injection zu ermöglichen ist durch den Konstruktor einer Klasse. Dieser miss mit der Annotation @Initializer annotiert werden damit die durch die Web Beans verwaltete Klasse auch richtig initialisiert wird (ähnlich dem @PostConstruct bei EJB 3.0). Zudem muss man die übergebene Web Bean nicht mit @Current annotieren weil bei Konstruktoren die Web Beans automatisch injected werden:

Möchte man auf eine Bean mit der Expression Language (EL) zugreifen muss die Bean durch einen Namen bekannt gemacht werden. Dazu dient die Annotation @Named. Dabei kann man der Annotation entweder einen Namen explizit mitgeben oder den Namen der Klasse verwenden. Wird der Name der Klasse verwendet ist auch der erste Buchstabe klein gestellt:

Einmal mit @Named bekannt gemacht kann diese Bean überall mit EL verwendet werden, wie hier in diesem Beispiel in einer JSF Seite:

Wer noch ein weitere kleine Einführung in Web Beans und somit in JEE 6 haben möchte sollte sich auch die Präsentation von Gavin King über die Web Beans anschauen. In diesem Artikel habe ich auch noch ein kleines Beispiel gepostet.

Java Contexts and DependencyInjection (JSR-299) is a new Java standard for dependency injection and contextual lifecycle management.

Wer Erfahrung mit dem JBoss Seam Framework hat wird viel Vertrautes im JSR 299 wiederfinden denn ähnlich wie für die JPA Spezifikation viel von Hibernate übernommen wurde ist für den JSR 299 viel von Seam übernommen worden.

Einen kleinen Einblick in JEE 6 und somit auch in den JSR 299 konnte man schon durch den Podcast von Dan Allen im Teil 2 hören. Nun hat Gavin King eine Präsentation über den JSR 299 gehalten und diese Folien, welche viele Code Beispiele enthalten, online gestellt.

Hier ist der dazugehörige Post auf dem “In Relation To” Blog (Direktdownload des PDFs).

Einen kleinen Ausschnitt aus der Präsentation möchte ich direkt hier posten und erläutern um das Grundprinzip von Dependency Injection mit dem JSR 299 in einer Webanwendung zu verdeutlichen.

Binding Types:
Ein Binding Type lässt einen Client zwischen verschiedenen Implementierungen (Interface) oder Ableitungen (Klassen) eines bestimmten Typs anhand eines Binding Type Namens wählen.

Dazu wird erst der eigentliche Binding Type, ähnliche wie ein EJB Intercetpor, definiert:

public
@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
@interface Informal {}

Dieser neue Binding Type mit dem Namen Informal kann nun an einer konkreten Klasse verwendet werden. So wird definiert, dass der Binding Type @Informal zu der konkreten Klasse InformalGreeting gehört:

@Informal
public class InformalGreeting extends Greeting {
  public String greet(String name) {
    return "hello " + name;
  }
}

Jetzt kommt das eigentliche Dependency Injection in der Bussiness Komponente, die selbst z.B. eine EJB oder auch zukünftig durch den JSR 299 einfach nur ein POJO sein könnte. Die Klasse Printer erhält die Informal-Implementierung des Oberklasse Greeter injected. Das wird durch den neuen definierten Typ mit der Annotation @Informal angegeben.

public class Printer {

  @Informal Greeting greeting;

  public void greet() {
    System.out.println( greeting.greet("Markus") );
  }
}

Möchte man jetzt z.B. noch eine formelle Begrüßung ermöglichen würde man einen zweiten Binding Type erstellen:

public
@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
@interface Formal {}

Diesen definiert man anschließend an einer weiteren Ableitung der Klasse Greeting:

@Formal
public class InformalGreeting extends Greeting {
  public String greet(String name) {
    return "hello " + name;
  }
}

Möchte man nun in seiner Business Komponente die formale Begrüßung verwenden tauscht man lediglich die Annotation aus:

public class Printer {

  @Formal Greeting greeting;

  public void greet() {
    System.out.println( greeting.greet("Markus") );
  }
}

Mehr über Binding Types im JSR 299 kann auch in der Web Beans Referenzdokumentation sogar auf deutsch nachgelesen werden.

Namen und Scope für Zugriff mit EL
Das zweite Beispiel soll zeigen wie einfach es in Zukunft werden soll eine Business Komponente der View via EL (Expression Language) zur Verfügung zu stellen. Dazu wird der unserer Business Komponente (Klasse) Printer einfach die Annotation @Named hinzugefügt und somit dieser Java Bean ein Name Vergeben (siehe auch Referenzdokumentation):

@Named("printer")
public class Printer {

  @Informal Greeting greeting;

  public void greet() {
    System.out.println( greeting.greet("Markus") );
  }
}

In der View kann ab sofort über den Namen “printer” darauf zugegriffen werden:

<h:commandButton value="Say Hello" action="#{printer.greet}"/>

Jetzt kann man der Business Komponente noch einen Scope (Geltungsbereich) geben. Bereits vorhandene Scopes sind @RequestScoped, @SessionScoped, @ApplicationScoped und @ConversationScoped. In diesem Beispiel wird @RequestScoped verwendet. Somit steht eine Instanz dieser Komponente einen kompletten Request lang zur Verfügung.
Um die Begrüßung etwas persönlicher zu machen kann man nun noch den Namen für die Begrüßung über die View angeben und direkt in der Business Komponente vie EL setzen. Dazu wird noch ein Attribut name benötigt:

@RequestScoped
@Named("printer")
public class Printer {

  @Informal Greeting greeting;
  private String name;

  public void greet() {
    System.out.println( greeting.greet(name) );
  }

  public void setName(String name) { this.name=name; }
  public String getName() { return name; }
}

Hier die dazugehörige angepasste View:

<h:form>
  <h:inputText value="#{printer.name}"/>
  <h:commandButton value="Say Hello" action="#{printer.greet}"/>
</h:form>

Die hier aufgezeigten zwei Beispiele zeigen nur einen kleinen Teil des JSR 299. Aber gerade die einfache Annotation @Named und die verfügbaren Scopes ist ein riesen Schritt in die Vereinfachung der Entwicklung von Webanwendungen. Wie schon erwähnt sind diese Erneuerungen in JEE 6 heute in JEE 5 durch Seam auch schon möglich.

Wer mehr über den JSR 299 wissen möchte sollte sich die Präsentation von Gavin King, das JSR 299 selbst, die Referenzdokumentation sowie die Referenzimplementierung mit seinen Beispielen mal genauer anschauen. Alternativ kann man sich natürlich auch einfach mit JBoss Seam beschäftigen, welches unter anderem die Basis für JSR 299 ist.

Wer sich mit Seam beschäftigt wird den Namen Dan Allen bestimmt schon das ein oder andere mal gehört haben. Er ist Commiter bei dem Seam Projekt und arbeitet mittlerweile auch bei JBoss. Vor allem sein Buch “Seam in Action” ist sehr zu empfehlen.

Nun wurde Dan Allen vor ein paar Tagen von Ken Rimple von Chariot Tech Cast interviewt und dieses Interview kann man sich als Podcast anhören bzw. herunterladen. Aufgrund der Länge des Interviews sind zwei Teile entstanden. Teil 1 ist ca 40 Minuten und Teil 2 ca 30 Minuten lang und beide sind meiner Meinung nach sehr hörenswert.

Im folgenden die Auflistung der in den beiden Teilen besprochenen Themen:
Themen Teil 1 (Direktdownload mp3):

• Allgemein über das Seam Framework
• Unterschied zu Spring und anderen Frameworks
• Wie Seam JSF und Pojos sowie EJBs zusammenbringt
• Einfacher Einstieg in die JPA API mit Seam

Themen Teil 2 (Direktdownload mp3):

• Die Zukunft mit Java EE 6 inkusive JSR 299 (WebBeans)
• Wie wird sich Seam weiterentwickeln wenn die neue JEE Spezifikation steht (Seam 3)
• Andere Frontendtechnologien wie z.B. Flex oder nur JavaScript (Ajax)
• Seam als Einstieg für Workflowmanagement mit jBPM

Das ganze Interview ist kurzweilig und sehr interessant. Hat man mit Seam schon gearbeitet und sind die Grundsätze von Seam klar ist der Teil 2 mit Java EE 6 wohl das interessantere.

Unit Tests sind vielen Entwicklern ein Begriff und in der Java Welt verbindet man diesen Begriff fast automatisch mit dem Testframework JUnit. Dabei steht als genereller Gedanke hinter Unit Tests einzelne kleine Teilbereiche (Units, Methoden, Funktionen) atomar und unabhängig von einer Umgebung und Abhängigkeiten zu testen. Man geht davon aus, dass wenn die einzelnen kleinen Teile eines Systems in Ihrerer Aufgabe funktionieren und diese korrekt tun das große Ganze auch Bestand hat. Dabei gelten nur die Zustände: Erfolg oder Fehler.

In diesem und folgenden Artikeln soll es um den JUnit Konkurrenten TestNG gehen. Das Testframework TestNG ist laut seinem Entwickler Cédric Beust aus der JUnit Frustration entstanden und das NG in TestNG bezieht sich auf Next Generation.

Wer diese Frustration nachlesen möchte kann dies hier und hier tun.

Nicht nur wegen dieser Aussage soll TestNG ein wenig näher begutachtet werden. Wer z.B. mit JBoss Seam arbeitet wird sehr schnell merken, dass Seam von Haus aus eine TestNG Unterstützung mitbringt. Auch andere Frameworks setzen auf TestNG. Aber auch ohne diese Frameworks bietet TestNG eine sehr gute Alternative zu dem schon genannten JUnit.

Das Ziel dieses ersten TestNG Artikels ist einfache TestNG Unit-Tests zu erstellen und aus Eclipse heraus ausführen zu können. In folgenden Artikeln wird es mehr in die Möglichkeiten von TestNG und in die Konfiguration von Tests und Testsuites gehen.

Um TestNG zu verwenden muss die aktuelle Version heruntergeladen werden. Zur Zeit ist die aktuellste Version 5.8 und kann hier direkt heruntergeladen werden.

Es besteht auch eine Eclipse Unterstützung für TestNG, die über eine Update Seite installiert werden kann. Dazu unter Eclipse 3.4 (Ganymede) über “Help->Software Updates…->Available Software Tab->Add Site…” klicken, die TestNG Update Site URL http://beust.com/eclipse angeben und mit “OK” bestätigen. Anschließend das neu hinzugefügte Element aufklappen, das Plugin TestNG selektieren und den Button “Install” drücken.

Bei der Installation den Anweisungen folgen. Es kam bei mir ab und an vor, dass bei der Bestätigung für die zu installierende Software nur ein leeres Fenster auftrat – da einfach mit “OK” weiter klicken.
Nach dem Neustart von Eclipse steht eine TestNG View zur Verfügung und kann geöffnet werden.

Um TestNG aus Eclipse heraus verwenden zu können müss die TestNG Bibliothek noch im Classpath referenziert werden. TestNG liefert zwei jars aus: eine für Java 1.4 (testng-5.8-jdk14.jar) und eine für Java 5 (testng-5.8-jdk15.jar). Beide liegen im heruntergeladenen TestNG.zip im Root Verzeichnis oder alternativ im TestNG Eclipse Plugin Ordner (eclipse\plugins\org.testng.eclipse_5.8.0.2\lib). In meinem Fall kopiere ich mir das testng-5.8-jdk15.jar in meinen im Projekt erstellten lib Ordner und gebe dieses im Projekt Classpath an (Rechte Maustaste auf den Projekt Ordner->Properties->Java Build Path).

Als Beispielprojekt bzw. Beispiel Source Code der getestet werden soll habe ich ein Java Projekt mit zwei Source Ordnern erstellt. Ich persönlich mag es lieber, wenn die Testklassen in einem getrennten Source Ordner liegen. So besteht bei mir der Source Ordner: src und test sowie ein normaler Ordner für die benötigten Java Bibliotheken lib. Unterhalb der zwei Source Ordern erstelle ich zweimal das gleiche Package. Anschließend in dem Ordner src die Klasse de.javathreads.util.Calc und in den Ordner test die Klasse de.javathreads.util.CalcTest. Nach getaner Arbeit sieht die Projektstruktur wie folgt aus:

Nun schauen wir uns den Source Code der zwei Klassen etwas genauer an. Die Klasse de.javathreads.util.Calc beinhaltete die einfachen Methoden add() und divide():

package de.javathreads.util;

public class Calc {

  public int add(int first, int second) {
    return fist + second;
  }

  public double divide(int first, int second) {
    if (second == 0) {
      throw new ArithmeticException();
    }
    return first / second;
  }
}

Um mit TestNG eine Methode zu definieren die den eigentlichen Unit-Test enthält wird diese mit der Annotation org.testng.annotations.Test versehen. Um abzuprüfen ob das Ergebnis dem erwarteten Ergebnis entspricht arbeitet TestNG mit Java Assertions und dem Schlüsselwort assert. Das sieht dann in meiner CalcTest Klasse, welche die Methode Calc.divide() testen soll, wie folgt aus:

package de.javathreads.util;

import org.testng.annotations.Test;

public class CalcTest {

  /**
   * Test für simples dividieren.
   */
  @Test
  public void divideSimple() {
    Calc c = new Calc();
    double sum = c.divide(4, 2);
    assert (sum == 2);
  }

  /**
   * Test für Division durch 0.
   */
  @Test
  public void divideByZero() {
    Calc c = new Calc();
    try {
      c.divide(4, 0);
    } catch (ArithmeticException ex) {
      assert (true);
      return;
    }
    assert (false);
  }
}

Bei einer Prüfung mit dem Schlüsselwort assert muss der Ausdruck immer true ergeben. Mehr zu Java Assertions kann auch in dem javathreads Artikel “Reservierte Schlüsselwörter in Java – Assertions” sowie im Java Blog Buch gefunden werden.

Durch das TestNG Eclipse Plugin ist ein Unit Test sehr einfach durch das Context-Menü direkt aus dem Package Explorer heraus zu starten. Dazu mit der rechten Maustaste direkt auf die Klasse klicken welche die mit @Test annotierten Methoden enthält und anschließend unterhalb des Menüpunkts “Run As” den Punkt “TestNG Test” anklicken:

Es ist auch möglich auf ein Package zu klicken und somit alle darin liegenden Testklassen zu starten.
Nach einem oder mehreren durchlaufenen Unit-Tests wird das Ergebnis in der TestNG View farblich hervorgehoben. Dabei wird farblich gezeigt ob generell alle Test positiv waren (grün) oder mindestens einer fehlgeschlagen ist (rot). Im folgenden ein Screenshot für den Fall das alle Tests positiv waren:

Ist mindestens ein Test fehlgeschlagen wird der Balken schön rot und man die fehlgeschlagene Methode erkennt man durch das rote Kreuz. Selektiert man diesen Test erhält man im rechten Fenster die Exception zu dem Fehler. Bei TestNG sind das immer java.lang.AssertionError, wie man im folgenden Screenshot sehen kann:

Mit einem Doppelklick auf die Methode gelangt man direkt in den Java Editor an die gewünschte Stelle der Testklasse. Es wäre nun auch möglich den Test im Debug Modus zu starten. Dazu anstatt “Run As” einfach den Test mit “Debug As” starten. Dabei natürlich nicht vergessen einen Breakpoint zu setzen ;).

In der Console können noch die Logausgaben und auch das Gesamtergebnis begutachtet werden. Treten Exceptions in der zu testenden Klasse auf sind diese auch in der Konsole sichtbar. Im folgenden die Konsolenausgabe des Positiven Tests:

Als letzte Information zu dieser kleinen Einführung noch der Hinweis, dass TestNG immer mit XML Konfigurationsdateien arbeitet. Der Vorteil wenn das TestNG Eclipse Plugin verwendet wird liegt darin, dass dieses Plugin die XML Datei generiert. Aktualisiert man im Package View das Projekt (Projekt selektieren und F5 drücken) erscheint die Datei temp-testng-customsuite.xml:

Schaut man in diese Konfigurationsdatei rein sieht man wie der einfachste Fall eines TestNG Tests vie XML konfiguriert werden kann. Die Testklasse wird direkt angegeben:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="JavaTestNGProject">
  <test verbose="2" name="de.javathreads.util.CalcTest" annotations="JDK">
    <classes>
      <class name="de.javathreads.util.CalcTest"/>
    </classes>
  </test>
</suite>

Man kann natürlich auch eine solche XML Konfigurationsdatei manuell erstellen und via Eclipse Kontextmenü als TestNG Test ausführen. Dazu legt man sie einfach mit im Test-Source Verzeichnis ab.

In diesem Artikel wurde gezeigt wie man TestNG in Eclipse einbindet und das Eclipse Plugin verwenden kann. Zudem wurde ein sehr einfacher Test geschrieben und ausgeführt. Grundsätzlich ist man nun also in der Lage Tests zu schreiben und diese auch auszuführen, was den ein oder anderen schon deutlich weiter bringen dürfte ;).
Im nächsten Artikel über TestNG wird mehr auf die Möglichkeiten mit TestNG eingegangen. Welche Annotationen gibt es und wie kann man sie einsetzen bzw. wo liegen die Vorteile.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
  version="1.0">

  <persistence-unit name="MyEJBApp">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>java:/MyEJBAppDatasource</jta-data-source>
    <properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
      <property name="hibernate.hbm2ddl.auto" value="validate"/>
      <property name="hibernate.show_sql" value="true"/>
      <property name="hibernate.format_sql" value="true"/>
    </properties>
  </persistence-unit>
</persistence>

Der interessante Punkt ist die Angabe des Hibernate Dialekts. Dieser wird mit dem Schlüsselwort hibernate.dialect konfiguriert:

<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>

Es werden von Hibernate relativ viele Dialekte angeboten, so dass eine breite Unterstützung für die verschiedenen Datenbanken besteht. Unter den Angebotenen sind die üblichen Verdächtigen wie z.B.

• DB2 (org.hibernate.dialect.DB2Dialect)
• PostgreSQL (org.hibernate.dialect.PostgreSQLDialect)
• MySQL (org.hibernate.dialect.MySQLDialect)
• Oracle (org.hibernate.dialect.OracleDialect)
• Sybase (org.hibernate.dialect.SybaseDialect)
• MS SQL Server (org.hibernate.dialect.SQLServerDialect)
• HSQLDB/HypersonicSQL (org.hibernate.dialect.HSQLDialect)
• Derby (org.hibernate.dialect.DerbyDialect)

und noch einige andere.

Was ich bisher nicht wusste ist, dass die Angabe des Dialektes optional ist. Lässt man die Angabe weg versucht Hibernate die korrekte Implementierung von org.hibernate.dialect.Dialect anhand der JDBC Metadaten herauszufinden die vom JDBC Treiber zurückgegeben/geliefert werden.
Für die gängigsten Datenbanken sollte es somit kein Problem sein den Dialekt einfach wegzulassen. Der große Vorteil an dieser Stelle wäre, dass man tatsächlich ein EAR relativ unabhängig von der Datenbank ausliefern könnte. Entscheidet man sich für das weglassen sollte man zumindest den Hibernate Konfigurationsparamater auf validate setzen um eine DB Schemavalidierung beim Starten der Anwendung zu haben.

<property name="hibernate.hbm2ddl.auto" value="validate"/>

Stimmt etwas mit dem für den dynamisch gefundenen Datenbankdialekt das Schema nicht würde zumindest eine Exception geworfen werden.

Nachlesen kann man das in der offiziellen Hibernate Dokumenation im Kapitel 3.4 unter “Optional configuration properties”. Gleich der erste beschriebene Parameter ist der hibernate.dialect.
In Kapitel 3.4.1, weiter unten auf dieser Seite, sind zudem alle implementierten Dialekte aufgelistet.

Man kann den Funktionsumfang für die Formatierungsmöglichkeiten soweit abspecken, dass nur noch das nötigste für den Benutzer möglich ist:

Wer den Editor live ausprobieren möchte kann dies auf der RichFaces Live Demo direkt tun. Die einfachste Variante den Editor einzubinden und zu verwenden ist:

<rich:editor value="#{myBean.editorContent}"/>

Die Editor Komponente selbst basiert auf den sehr bekannten TinyMCE JavaScript WYSIWYG Editor und bisher musste man, wenn man einen solchen Rich Editor wollte, diesen manuell in sein Projekt einbinden.

Ich werde den Editor die Tage mal ausprobieren und dann wird man sehen ob er sich so einfach einbinden und verwenden lässt wie es bei den vielen anderen RichFaces Komponenten war.

Neben dem Editor ist noch eine weitere Ajax Komponente hinzugekommen: Ajax Queue. Mit dieser ist es möglich direkt hintereinander abgesetzte Ajax Request so zu managen, dass der zweite Ajax Request erst abgesetzt wird wenn der erste beendet wurde. Somit kann man parallele Ajax Requests verhindern.

Wer bisher noch nichts von den RichFaces bzw. das dazugehörige Ajax4Jsf gehört hat der sollte sich auf der Live Demo Seite die vielen Beispiele mal ansehen. Neben den fertigen Ajax Komponenten wie z.b. die DataTable, Inplace Edit, Tree oder File Upload (um nur einige zu nennen) ist vor allem der Ajax4Jsf Teil sehr interessant. Mit diesem lassen mit einfachen Mitteln bzw. Komponenten normale JSF Seiten “Ajaxifizieren” (a4j:support), es lassen sich JavaScript Methoden dynamisch erzeugen (a4j:jsfunction) die mit JSF Managed Beans reden oder Teile der JSF Seite neu Rendern oder man kann den Server mit Hilfe von Ajax Anfragen um z.B. einen Status abzufragen (a4j:poll).
Persönlich finde ich genau diesen Ajax4Jsf Teil und die gesamte Einfachheit der Verwendung der RichFaces Komponenten den Grund warum ich die JBoss RichFaces sehr empfehlen kann.

Noch ein letzter Tipp: Wer mit den RichFaces arbeitet sollte sich auf alle Fälle die JBoss Tools in Eclipse installieren um die direkte RichFaces Unterstützung im JSF Editor zu erhalten. Neben Autocomplete bei den Komponenten, dem Rich Editor für JSF oder xhtml Seiten erkennt er auch Expressions und kann auf die Methoden und Beans referenzieren.

Viel Spass beim ausprobieren!