Java WebApplications mit Eclipse

Eclipse lässt sich einfach aus dem Archiv auspacken und unter einem beliebigen Pfad installieren (unter Windows z.B. „C:\Programme\Eclipse“) unter Linux (Suse 8.1) unter „/opt/eclipse“. Wichtig für Suse 8.1: die Bibliothek gtk 2.0 muss installiert sein.

Alle Plugins liegen unter dem Installationsverzeichnis im Verzeichnis plugins, darunter die einzelnen Packages mit umgekehrten Domainnamen als Verzeichnisse (z.B. org.eclipse.jdt… ).

Um weitere Plugins zu installieren genügt es, diese entsprechend in die Verzeichnishierarchie zu entpacken und dann Eclipse neu zu starten. Neue Plugins werden dann automatisch erkannt und eingerichtet.

Der Umgang mit Eclipse gestaltet sich erheblich einfacher, wenn man ein paar grundlegende Begriffe und wie diese in Eclipse verwendet werden verstanden hat.

Zunächst einmal sollte man dafür sorgen, dass die Sourcecodes grundsätzlich von den erzeugten Class-Files getrennt bleiben. Hierfür ändert man im Dialog „Windows - Preferences“ den Source-Folder-Name auf „src“ und die Output-Location auf „bin“.

Abbildung 3.1. Preference – New Project

Für Web-Applikationen ist es evtl. Geschickter das Output-Verzeichnis gleich so einzustellen, dass alles Class-Files dort landen, wo der Applicationserver sie erwartet („web/WEB-INF/classes“). Das kann man aber auch in der Project-Preferences für jedes Projekt getrennt einstellen.

Abbildung 3.2. Properties – Build output folder

3.1.1. Classpath-Variablen

Ausser der Laufzeit-Bibliothek wird man bei grösseren Projekten sehr schnell andere Bibliotheken mit einbinden müssen. Da diese bei jedem Entwickler auf unterschiedlichen Pfaden installiert sein können, benutzt man sogenannte Classpath-Variablen.

Abbildung 3.3. Preferences – Classpath Variables

Im Projekt werden so nur symbolische Namen gespeichert, die jeder Entwickler auf seine lokale Installation anpassen kann. Braucht man z.B. „servlet.jar“ von Tomcat, dann wird sie im Projekt als „TOMCAT_HOME/common/lib/servlet.jar“ referenziert. Wo Tomcat dann genau installiert ist, wird vom Entwickler selbst festgelegt in dem er den Wert von TOMCAT_HOME entsprechend seiner lokalen Installation einstellt.

3.1.3. Erweitern der Dokumentation

Man kann die eingebaute Dokumentation sehr leicht erweitern mit eigenen Texten erweitern. Zum einen lassen sich alle mit JavaDoc erzeugten API-Dokumentationen direkt einbinden. Das gilt zu allererst natürlich für das Java-SDK selbst, aber dann natürlich auch für alle im Projekt benutzten Bibliotheken.

Zum anderen können Plugins ihre Dokumentation nahtlos integrieren, als Beispiel gibt's im Download-Bereich diesen Artikel auf als Plugin, wo durch er eben in der Eclipse Hilfe erscheint.

Abbildung 3.4. Properties für eine Bibliothek

Um die Möglichkeiten voll auszunutzen, sollte man zu jeder verwendeten Bibliothek (JAR-File) die entsprechende API-Dokumentation, sowie den Sourcecode (soweit verfügbar) zuordnen. Wenn man ein komplettes JDK installiert inklusive Source erkennt Eclipse das automatisch. Für alle individuellen Bibliotheken ordnet man über die Properties eines jeden JARs (erreichbar über das Kontextmenü) die Dokumentation und das Source-Archiv zu.

Entsprechend wird auch die API-Dokumentation des eigenen Projekts mit eingebunden:

Abbildung 3.5. Properties – eigene Dokumentation einbinden

So vorbereitet liefert den Druck auf Shift-F2 jederzeit die Dokumentation zum Objekt unter dem Cursor, genauso wie F3 das betreffende Sourcefile öffnet.

3.1.4. Beispielprojekt für Tomcat

Dies Beispiel soll zeigen, wie man zunächst noch ohne spezielle Unterstützung von Plugins ein Projekt mit Tomcat aufbaut. Der Package-Explorer zeigt folgende Struktur:

Abbildung 3.6. Tomcat Projektstruktur

Neben dem src Verzeichnis gibt es bei WebApplications immer das Verzeichnis „web“ und darin das „WEB-INF“, das alle Metainformationen und die zu erzeugenden Class-Files enthält. Die Output-Build-Location (siehe oben) wurde so umgestellt, dass die erzeugten Class-Files direkt im „classes“ landen.

Daneben sind alle „normalen“ Web-Resourcen wie HTML-Dateien, Grafiken usw. in „web“ untergebracht. Auch die JSP-Seiten werden dort angelegt.

Grundsätzlich reicht das schon aus, um eine erste Anwendung mit Tomcat zu erstellen. Das Deployment ist allerdings noch nicht sehr komfortabel: man muss alle Dateien des Workspaces unter „web“ in ein Verzeichnis unter das WebApps-Verzeichnis von Tomcat kopieren und anschließend Tomcat neu starten. Das geht entweder ganz manuell mit einem Script oder per Export mit Eclipse im File-Menü.

Während der Entwicklungsphase kann man sich das Deployment aber auch schenken und stattdessen einen Tomcat-Context erzeugen, der direkt auf die WebApplication im Workspace von Eclipse verweist. Hierzu wird ein Eintrag in der server.xml in TOMCAT_HOME/conf von Tomcat erstellt:

<Context reloadable = "true" displayName="Develop"
docBase="C:\Programme\eclipse\workspace\Test-Servlet\web" cookies="true"
path="/test"/> 

Diesen Eintrag fügt man hinter die anderen Kontexte ein und startet Tomcat neu.

Was dann aber immer noch nicht geht, ist das Debuggen der Application. Diese speziellen Aspekte werden in den Kapiteln 7 und 8 erläutert.

Im Context-Menü des Projekts unter Team „Share Project“ auswählen:

Abbildung 4.1. Projekt ins CVS einbinden

Wer zuvor noch nie mit CVS gearbeitet hat, muss nun zuerst eine Repository-Location anlegen, damit also bestimmen, welchen CVS-Server man verwenden möchte. Wenn schon mal mit CVS gearbeitet wurde, dann werden die bereits bekannten CVS-Server aufgelistet und man kann einfach einen auswählen.

	Das Löschen einer Repository-Location geht nur in der CVS-Perspective im CVS-Locations-View: im Kontextmenü auf „Discard-Location“ klicken.

Abbildung 4.2. Repository wählen

Das Erstellen einer Repository-Location fragt nun eine Reihe von Parametern ab:

Abbildung 4.3. Repository-Location neu erstellen

Host und Repository path definieren, wo das Projekt zu finden ist bzw. wo es gespeichert werden soll. Authentication legt die Informationen für das Login zum CVS-Server fest. Connection spezifiziert die Art der Verbindung (normalerweise im „pserver“).

Dann bleibt nur noch auszuwählen, ob der Projektnamen auch als CVS Modulnamen verwendet werden soll. CVS verwaltet alles in Modulen, was im Repository einem Verzeichnis auf oberer Ebene entspricht. Normalerweise wählt man Projektnamen und Modulnamen identisch, dann kann keine Verwechslung passieren.

Anschließend wird das Projekt im Synchronize-View angezeigt:

Abbildung 4.4. Neues Projekt im Synchronize-View

Die Symbole bedeuten, dass die lokalen Verzeichnisse und Dateien im Repository noch nicht bekannt sind und daher mit „Add to Version-Control“ und anschließendem „Commit“ endgültig unter die Verwaltung des CVS gestellt werden.

Für das ganze Projekt geschieht dies im Kontextmenü des Projekts. Beim „Commit“ wird abschließend noch ein Dialog angezeigt, der jedem Übertragen ins Repository das Eintragen eines Kommentars erlaubt.

Die Klammern neben den Dateinnamen (ASCII -kkv) oder auch (Binary) kennzeichnen die Dateiart, wie sie vom CVS gesehen werden. Im ASCII-Modus können Änderungen sehr komfortabel angezeigt und verwaltet werden. Die Option -kkv bewirkt, dass bestimmte Platzhalter in den Dateien vom CVS automatisch ersetzt werden. So kann z.B. die Versionsnummer immer aktuell in den Text einer Ausgabe eingebaut werden.

In den beiden Dateien „.project“ und „.classpath“ verwaltet Eclipse die Metainformationen zu jedem Projekt. Es ist daher wichtig, dass diese Dateien immer mit eingecheckt werden. Wenn man sich an die Grundeinstellungen von Kapitel 3.1.1 hält und nur mit Classpath-Variabeln arbeitet und absolute Bezüge ganz vermeidet, dann kann jeder im Team das Projekt aus dem CVS auschecken und sofort damit arbeiten.

In Eclipse geht das im Repository-View besonders komfortabel mit „Checkout as Project“ was bei jedem Verzeichnis im Kontextmenü angeboten wird.

Abbildung 4.5. Projekte auschecken

Kann mit auf das Repository nur per SSH zugreifen, so muss man, besonders unter Windows, einen SSH-Client zusätzlich installieren, der die Verbindung herstellt. Für Windows gibt es seit langem den freien Client Putty, der mehrere Serviceprogramme^[2] mitbringt. Was für den Remotezugriff per SSH gebraucht wird, ist plink.exe. Unter „Windows/Preferences/Team/CVS/Ext Connection Method“ wird es konfiguriert:

Abbildung 4.6. Ext Connection konfigurieren

Als Parameter muss eingetragen werden „{user}@{host} -pw {password} -ssh“. Damit lassen sich sichere Verbindungen zum Repository aufbauen, so dass man auch übers Internet bequem arbeiten kann.

Wie jedes andere Plugin wird das Zip-File in die Verzeichnishierarchie von Eclipse entpackt.

Achtung: Die plugin.xml Datei im Verzeichnis ECLIPSE_HOME/plugins/com.objfac.xmleditor_0.2.8 enthält eine Importanweisung für das PDE-Plugin^[3] von Eclipse (was man aber eigentlich nur als Entwickler von Plugins braucht). Wenn das PDE nicht installiert ist, startet XML-Buddy deshalb nicht. Man kann die Importanweisung aber gefahrlos auskommentieren.

   ...
 <requires>
     <import plugin="org.eclipse.ui"/>
     <import plugin="org.eclipse.core.resources"/>
     <import plugin="org.eclipse.core.runtime"/>
     <import plugin="org.eclipse.swt"/>
     <import plugin="org.apache.xerces"/>
     <import plugin="org.eclipse.jdt.ui"/>
     <import plugin="org.eclipse.search"/>
     <!-- sr <import plugin="org.eclipse.pde"/> --> 
 </requires>
 ...

Diese Zeile wird wie im Ausschnitt der plugin.xml auskommentiert.

XML-Buddy kann mit Hilfe einer DTD oder eines Schemas die editierten XML-Dateien auf ihre Gültigkeit überprüfen. Er unterstützt einen Cache für schon verwendete DTDs, so dass diese nicht immer aus dem Internet herunter geladen werden müssen.

Abbildung 5.1. XML-Buddy Vervollständigung von Child-Elementen

Die DTD bzw. das Schema definiert die Struktur eines XML-Dokuments, was XML-Buddy dazu nutzt beim Editieren automatisch Vorschläge anzuzeigen wie der Code komplettiert werden könnte.

Abbildung 5.2. XML-Buddy Strukturanzeige

Als Navigationshilfe liefert XML-Buddy einen „Outline-View“, der die Struktur des XML-Dokuments mit einer Baumansicht darstellt.

Zunächst wird das ZIP-Archiv in die Verzeichnishierarchie von Eclipse entpackt. Nach dem Neustart von Eclipse läßt sich das Plugin unter „Windows / Preferences“ konfigurieren:

Abbildung 6.1. Tomcat-Plugin Konfigurieren

Die wichtigsten Einstellungen sind:

Damit kann das Plugin bereits benutzt werden. Unter „Windows / Customize Perspective“ aktiviert man nun in der „Debug-Perspective“ das Tomcat-Plugin:

Abbildung 6.2. Tomcat-Plugin aktivieren

Nun erscheinen in der Toolbar drei neue Buttons über die man Tomcat direkt unter Eclipse starten und stoppen kann.

Das interessante daran ist, dass man so eine komplette WebApplication inklusive Tomcat debuggen kann. Man kann also ohne weiteres in die Methoden des TestServlets einen Breakpoint setzen und wenn man nun mit einem Browser das Servlet aufruft, bleibt der komplette Request genau in der Servlet-Methode stehen.

6.1.1. Projekt als „Tomcat-Projekt“

Wenn man ein Project neu anlegt ist fortan Tomcat-Projekt neben Java-Projekt als neuer Projekttyp verwendbar. Ein bestehendes Projekt läßt unter „Projekt-Properties“ zum „Tomcat-Projekt“ machen:

Abbildung 6.3. Tomcat-Projekt Einstellungen

• Zunächst muss „Ist ein Tomcat Project“ angekreuzt sein.

• Bei Anwendungs URI wird der Context-Pfad eingetragen mit dem der Tomcat-Context an gelegt werden soll.
• Wenn „Kann .XML aktualisieren“ angekreuzt ist, dann wird der Tomcat-Context automatisch in die server.xml eingetragen.
• „WAR file for export“ legt den Namen des WAR-Files fest, wenn das Projekt exportiert wird. Der Name ist allerdings ein absoluter Pfadnamen, d.h. der Pfad verweist direkt auf das Verzeichnis in das deployed werden soll.

Wenn alles so vorbereitet ist, dann ist im Kontextmenü des Projekts ein zusätzlicher Eintrag vorhanden:

• Abbildung 6.4. Tomcat-Projekt Optionen im Kontextmenü

  
  Das WAR^[4]-File läßt sich ausliefern.
• Der Context in der Tomcat-Konfigurationsdatei kann entfernt bzw. aktualisiert werden.
• Die Tomcat-Bibliotheken können auf Knopfdruck alle zum Projekt hinzugefügt werden.
• Es wird ein Arbeitsverzeichnis erzeugt, welches die aus JSP-Seiten erzeugten Servlets aufnimmt (wozu das gut ist, sieht man später unter ).

ObjectLearn hat mit seinem Plugin ein sehr mächtiges Werkzeug zum Erstellen von J2EE Applicationen vorgelegt. Was hier vorgestellt wird ist nur ein Ausschnitt aus der gesamten Funktionalität, der sich mit WebApplications beschäftigt. Der ganze EJB-spezifische Teil wird hier zunächst ausgespart.

6.2.1. Installieren und Einrichten

Zunächst wird das ZIP-Archiv in die Verzeichnishierarchie von Eclipse entpackt. Nach dem Neustart von Eclipse läßt sich das Plugin unter „Windows / Preferences“ konfigurieren:

Abbildung 6.5. Konfiguration von Lomboz 1

Zunächst gibt man den Pfad zur tools.jar vor. Das ist die Bibliothek aus dem JDK welche den Compiler enthält. Falls man mehrere JDKs installiert hat, sollte man darauf achten, dass der Compiler des JDKs verwendet wird, welches auch für das Projekt eingestellt ist.

Abbildung 6.6. Konfiguration von Lomboz 2

Dann wählt man die passenden Parameter für die Tomcat-Installation.

Die Einstellungen des JSP-Editor sind eher kosmetischer Natur und sollen hier nicht weiter erwähnt werden.

Damit die verschiedenen Views und Actions sichtbar werden, muss man in der Java-Perspective über „Customize Perspective“ (genau wie oben beim Tomcat-Plugin) einige der Lomboz-Optionen aktivieren:

Abbildung 6.7. Konfiguration von Lomboz 3

Entsprechend werden im Zweig „Windows / Show View“ der „Lomboz J2EE View“ aktiviert und im Zweig „Other“ die „Lomboz Actions“.

Neben den Wizards zur Erstellung neuer Resourcen, kommt in der Taskleiste damit ein neuer Button „J2EE Project Builder“ hinzu.

Damit lassen sich sehr schnell sogenannte Container erstellen. Unter Container versteht Lomboz z.B. Einen WebContainer also genau das, was in unserem Beispielprojekt das Verzeichnis „web“ schon ist.

Damit Lomboz den vorhandenen Web-Container erkennt, muss eine Datei build.xml und servers.xml im Verzeichnis WEB-INF vorhanden sein (neben web.xml die sowieso immer da liegt).

Was in den beiden Dateien drinstehen muss, erfahren wir am besten, wenn wir einfach einen neuen „Web-Container“ anlegen. Man öffnet den J2EE Project-Outliner und klickt „Add Container“. Der folgende Dialog erscheint:

Abbildung 6.8. Hinzufügen eines Containers

Nun fügen wir einen Web-Container hinzu und geben ihm den Namen „test“ („web“ gibt es ja schon). Dann schaltet man zunächst weiter auf den Reiter „Servers“ und definiert als Applicationserver Tomcat:

Abbildung 6.9. Servertyp für den Container

Sobald der Dialog mit Finish verlassen wird, sehen wir im Package-Explorer den neu erstellten Container.

Abbildung 6.10. Struktur des Web-Containers

Er enthält neben den normalen Verzeichnissen „WEB-INF“ und „classes“ auch gleich das Verzeichnis „lib“. Zusätzlich zum Deploymentdescriptor „web.xml“ erzeugt Lomboz auch noch die Dateien build.xml, build.properties, servers.xml und weblogic.xml.

Die build.xml ist eine Ant-Build-Datei mit drei Targets „deploy“, „init“ und „undeploy“. Ähnlich wie zuvor beim Sysdeo-Plugin wird hierüber das Deployment gesteuert. Man kann allerdings durch abändern der build.xml und der build.properties beliebig erweitern oder an eigene Bedürfnisse anpassen.

Die Datei servers.xml beschreibt den Applicationserver für diesen Container. In unserem Fall also wie zuvor eingestellt den Tomcat. Welche Parameter sich genau dahinter verbergen, kann man durch öffnen der Datei nachschauen.

weblogic.xml schließlich ist der Deploymentdescriptor für einen Bea-WebLogic-Server, da wir diesen zunächst nicht weiter betrachten, kann die Datei weblogic.xml wieder gelöscht werden.

Weiterhin werden im web Verzeichnis selbst gleich zwei JSP-Seiten angelegt: „index.jsp“ und „error.jsp“.

Wie man sieht kann mit diesem Wizard schnell ein kompletter WebContainer erzeugt werden.

Um nun das bestehende Verzeichnis „web“ in unserem Projekt für Lomboz zum WebContainer zu machen, kopieren wir einfach die Dateien build.xml, build.properties und servers.xml in das „web“-Verzeichnis. Damit wird „web“ für Lomboz auch zum WebContainer.

Nun kann man den Lomboz J2EE View nutzen und sich die Container darin anschauen:

Abbildung 6.11. Lomboz J2EE View

Über die Kontextmenüs und die Pushbuttons am rechten, oberen Fensterrand lassen sich nun verschiedene Aktionen starten, die zuvor in der build.xml definiert wurden. Was über die Standard-Target hinaus in der build.xml integriert wurde, muss per „Run Ant“ direkt aufgerufen werden.

Neben dem Verwalten von J2EE Containern, kann Lomboz noch mehr Unterstützung leisten. Es gibt Wizards zum Erzeugen von diversen Objekten. Ausser den EJB bezogenen sind dies folgende:

Abbildung 6.12. Lomboz JSP Wizard

Eine weitere Funktionalität sind die Actions, also Befehle die im Kontextmenü von WebContainern zur Verfügung stehen:

Abbildung 6.13. Lomboz J2EE Actions im Kontextmenü

Die meisten dieser Befehle sind selbsterklärend und müssen nicht nochmal beschrieben werden. Eine Besonderheit ist allerdings der Syntaxcheck von JSP-Seiten. Den gibt es nicht nur als Action im Menü, sondern der ist auch im Editor eingebaut.

Das Problem kennt jeder: JSP-Seiten fehlerfrei zu erstellen ist viel schwerer als normalen Servletcode. Das kommt einfach daher, dass die Unterstützung mit Autovervollständigung, inkrementellem Compiler, Syntaxcheck und Syntaxhighlightning bei pure Java viel besser ist als bei JSP-Seiten. Mit Lomboz stimmt das alles nicht mehr.

Fehler werden durch inkrementellem Compilieren auch der JSP-Seiten gleich beim abspeichern erkannt:

Abbildung 6.14. Lomboz JSP Editor Fehler in der JSP-Seite

Selbst die vom Java-Quelltexteditor gewohnte Unterstützung mit Autovervollständigung und Popuphelp funktioniert wie gewohnt:

Abbildung 6.15. Lomboz JSP Editor mit Autovervollständigung und Popuphelp

Dadurch ergeben sich natürlich grosse Effizienzsteigerungen, weil die Fehlerwahrscheinlichkeit deutlich zurück geht.

Zusätzlich ein build.xml für externe Builds und spezielle Builds, wie z.B. Deploy, install, doc oder ähnliche. build.properties für lokale Buildumgebung. Siehe Lomboz build.xml.

Eine eigene Start-Konfiguration zu erstellen, geht wie folgt:

Im Run-Menü, die Option „Run...“ wählen und folgenden Dialog erscheint:

Abbildung 7.1. Start-Konfiguration erstellen

Neben Zuordnung zu einem Projekt und dem Benennen muss vor allem der Start-Punkt festgelegt werden. Im Falle von Tomcat ist das „org.apache.catalina.startup.Bootstrap“ das im „bootstrap.jar“ im bin-Verzeichnis von Tomcat liegt. Als Argument muss man „start“ übergeben und falls noch nicht geschehen, muss das Archiv „bootstrap.jar“ auch in den Classpath aufgenommen werden. Dies alles erledigt man in den unterschiedlichen Abschnitten des Dialogs und hat damit eine Startkonfiguration für Tomcat erstellt.

Die Argumente an die VM (zweiter Reiter „Arguments“) müssen so aussehen:

-DJAVA_HOME="C:/Programme/Java/j2sdk1.4.1_01" -Dcatalina.base="C:/Programme/Apache Group/Tomcat 4.1" -Dcatalina.home="C:/Programme/Apache Group/Tomcat 4.1" -Djava.io.tmpdir="C:/Programme/Apache Group/Tomcat 4.1\temp" -Djava.endorsed.dirs="C:/Programme/Apache Group/Tomcat 4.1\bin;C:/Programme/Apache Group/Tomcat 4.1\common\endorsed

Wobei man das Verzeichnis „C:/Programme/Apache Group/Tomcat 4.1/“ durch das gültige Installationsverzeichnis ersetzen muss.

Analog kann man zum Herunterfahren des Servers vorgehen. Der einzige Unterschied: als Argument wird „stop“ eingetragen.

Das Tomcat-Plugin von Sysdeo macht das Starten und Stoppen von Tomcat noch etwas einfacher. Wenn in der Debug-Perspective das Plugin aktiviert ist, dann stehen in der Taskleiste automatisch entsprechende Buttons für „Start“, „Stop“ und „Restart“ zur Verfügung.

Entsprechend der Vereinfachung mit Sysdeo Tomcat-Plugin gilt auch für Lomboz: für jeden WebContainer ist Start und Stop schon vordefiniert und direkt als Action ausführbar. Entweder im Contextmenü oder im J2EE-View in der Titelleiste (siehe Abbildung)

Mit einem so innerhalb von Eclipse gestarteten Tomcat kann man nun nach Belieben Breakpoints setzen und Schritt für Schritt, durch den Code des Servlets durch marschieren. Natürlich muss der Aufruf von aussen auch noch angestossen werden, im einfachsten Fall in dem wir die Seite einfach im Browser aufrufen.

Abbildung 7.2. Servlet im Debug-Modus auf einem Breakpoint

Ab der Version 1.4.1 der Java VM funktioniert das Codereplacement auch endlich recht gut. D.h. Man kann einer laufenden Anwendung neuen Code unterschieben. Wenn man z.B. während des Debuggens einen Fehler feststellt und gleich korrigiert, dann wird nach dem Abspeichern in Eclipse dieser Code sofort in die laufende Application übernommen.

Damit alles richtig funktioniert sind folgende Schritte notwendig:

Punkt 1 wird vom Lomboz-Plugin automatisch erledigt. Das Verzeichnis „j2src“ ist Ihnen vielleicht schon aufgefallen.

Punkt 2 erfolgt analog wie die Änderung des Contextes in der Tomcat-Konfigurationsdatei (siehe Abschnitt 3.1.4)

<Context reloadable = "true" displayName="Develop"
docBase="C:\Programme\eclipse\workspace\Test-Servlet\web" cookies="true"
path="/test"/
workDir="C:\Programme\eclipse\workspace\Test-Servlet\j2src\org\apache\jsp" />

hier wird genau auf das „j2src“-Verzeichnis verwiesen, damit Jasper die generierten Servlets darin ablegt.

Der Grund warum das „workDir“ auf „org\apache\jsp“ endet ist derselbe, der es auch erforderlich macht Tomcat zu patchen^[5]:

Damit die Servlets in Eclipse compiliert werden können müssen die Package-Deklarationen zu den Verzeichnissen passen. Das Standard-Package für JSP-Servlets ist immer „org.apache.jsp“ und der Tomcat-Patch sorgt nun dafür, dass für Seiten, die nicht auf der obersten Ebene des Webservers liegen, die Package-Deklaration von Jasper entsprechend erweitert wird.

Eine JSP-Seite mit der URI „/test/index.jsp“ erhält demnach das Package „org.apache.jsp.test“.

Zunächst muss man sich die zwei geänderten Class-Files bei Sysdeo herunterladen (findet man im unteren Teil der Seite http://www.sysdeo.com/eclipse/tomcatPlugin.html.

	Achtung: Für die Version 4.1.12 und 4.1.18 werden unterscheidliche Patches benötigt.

Um den Patch zu installieren muss man drei Class-Files an die richtig Stelle kopieren bzw. in das bestehende JAR-File integrieren. Hat man die Class-Files einzeln unter TOMCAT_HOME/common/classes, kopiert man die aus dem ZIP-Archiv einfach darüber.

Liegen die Class-Files unter TOMCAT_HOME/common/lib als JAR-Archiv vor, so muss man die dort Class-Files des Archivs ersetzen (z.B. mit WinZip). Bitte machen Sie vorher eine Sicherheitskopie von den betreffenden Dateien, damit nichts schiefgehen kann.

Wenn alles so weit vorbereitet ist, dann können wir loslegen: zwei JSP-Seiten haben wir schon und zum Testen erzeugen wir im Verzeichnis „test“ eine weitere Seite „bug.jsp“.

Abbildung 8.1. neue JSP-Seite zum Debuggen

Nun rufen wir die Seite mit dem Browser auf und tatsächlich erhalten wir nicht das gewünschte Ergebnis.

Da Eclipse von den im Hintergrund durch Jasper kompilierten Seiten nichts mitbekommt, müssen wir zunächst im Contextmenü von „j2src“ auf „Refresh“ klicken.

Jetzt sieht man alle bereits kompilierten JSP-Servlets im Projekt-Workspace. An der interessanten Stelle setzen wir nun einen Breakpoint und rufen die Seite nochmal im Browser auf: et vóila.

Abbildung 8.2. JSP-Seite im Debugger

Abbildung.

Junit wird von Eclipse durch einen speziellen Typ von Run-Configuration und einer eigenen View unterstützt, welche die Testergebnisse anzeigt und den letzten Test erneut starten kann.

Um einen Unittest zu schreiben erweitert man einfach „junit.framework.TestCase“ und fügt lauter Methoden ein, die mit dem Namen „test“ beginnen (z.B. „testMethod1“ ). Mit Hilfe einiger Methoden aus dem Junit-Framework überprüft man anschließend die Ergebnisse.

Beispiel:

import junit.framework.TestCase;

/**

* A simple TestCase to show how junit works.

* @author sr

*/

public class MyFirstTest extends TestCase {

    public MyFirstTest( String name ) {

        super( name );

    }

    public void testFoo( ) {

        Foo foo = new Foo();

        String s = foo.getString( 1 );

        assertNotNull( s );

    }

}

Damit Unittests mit Servlets durchführbar sind, bedarf es einiger Vorbereitungen. Zu einen laufen Servlets nur in einer ganz bestimmten Umgebung, dem Servlet-Container (z.B. Tomcat), zum anderen werden Servlets nicht direkt aufgerufen, sondern indirekt über einen HTTP-Request.

Sie liefern auch nicht immer direkt Ergebnisse in Form eines Wertes oder einer HTML-Seite zurück, sondern verändern vielleicht nur den Zustand der serverseitigen Session.

Um all diesen Randbedingungen gerecht zu werden, wurde Cactus geschrieben.

Cactus erweitert JUnit und liefert alles was zum Testen von Servlets, JSP-Seiten und Filtern gebraucht wird:

<servlet>

   <servlet-name>ServletTestRunner</servlet-name>

   <servlet-class&gt;

     org.apache.cactus.server.runner.ServletTestRunner

   </servlet-class&gt;

</servlet>

<servlet-mapping>

     <servlet-name>ServletTestRunner</servlet-name>

     <url-pattern>/ServletTestRunner</url-pattern>

</servlet-mapping>

9.3.2. Ein erster Test

Als zweiten Schritt muss man nun noch einen Test schreiben, der ein Servlet testet und seiner Web-Applikation hinzufügen. Hierzu wird einfach eine Klasse erzeugt, die „ServletTestCase“ erweitert und ähnlich wie bei JUnit eine oder mehrere testXxx-Methoden enthält. Beispiel:

import junit.framework.Test;

import junit.framework.TestSuite;

import org.apache.cactus.ServletTestCase;

import org.apache.cactus.WebRequest;

import de.rinke.SaveToSessionServlet;

public class TestServlets extends ServletTestCase

{

     public TestServlets(String theName)

     {

         super(theName);

     }

     public static Test suite()

     {

         return new TestSuite(TestServlets.class);

     }

     public void beginSaveToSessionOK(WebRequest webRequest)

     {

         webRequest.addParameter("testparam", "it works!");

     }

     public void testSaveToSessionOK()

     {

         SaveToSessionServlet servlet = new SaveToSessionServlet();

         servlet.saveToSession(request);

         assertEquals("it works!", session.getAttribute("testAttribute"));

     }

     public void testHelloWorld() {

         assertNotNull( null );

     }

}

• Als Erweiterung zu normalen Unittest mit JUnit wird der Aufruf des Servlets mit beginXxx Methoden vorbereitet. Hier werden bestimmte Parameter in den Request „eingesetzt“, die das Servlet als Aufrufparameter erwartet. Normalerweise kommen diese Parameter aus dem Request des Browsers im TestCase werden die Parameter extra erzeugt.
• Dieser Test wird dann erfolgreich sein, wenn das Servlet ein bestimmtes Attribut in der Session erzeugt. Das passende Servlet zu schreiben sollte nicht schwer fallen.
• Dieser Test wird immer scheitern, weil eine der Assert-Methoden hier „assertNotNull“ also „stelle sicher, dass ungleich null“ direkt mit „null“ aufgerufen wird. Dies ist hier nur zum Ausprobieren eingesetzt, um zu demostrieren, wie ein TestCase scheitert.

Wenn man ein solches Projekt anlegt und die richtige URL im Browser aufruft, wird der TestCase auf dem Server ausgeführt und das Ergebnis angezeigt (http://localhost:8080/tomcat-test/ServletTestRunner?suite=de.rinke.test.TestServlets):

Abbildung 9.1. Testergebnis in XML

Wenn man das Ganze noch etwas hübscher aussehen lassen will, kann man noch ein Stylesheet hinzufügen und schon sieht das so aus (http://localhost:8080/tomcat-test/ServletTestRunner?suite=de.rinke.test.TestServlets&xsl=cactus-report.xsl):

Abbildung 9.2. Testergebnis mit einem Stylesheet formatiert

Das komplette Projekt kann man hier herunterladen.