17.3 Servlets und Java Server Pages entwickeln und testen

Um Servlets und Java Server Pages entwickeln und testen zu können, benötigen wir einen Servlet-fähigen Web-Server beziehungsweise einen Servlet-Container. Mittlerweile gibt es eine große Anzahl von Herstellern, deren Server Servlets verwalten.

17.3.1 Servlet-Container

Servlets und Applets sind konzeptionell ähnlich. Daher kann ein Vergleich gewagt werden: Applets werden vom Web-Browser geladen und gestartet. Den Browser können wir dabei als Container für Applets sehen, der eine Infrastruktur wie die virtuelle Maschine oder Netzwerkeigenschaften bereitstellt. Innerhalb einer Java-Umgebung im Browser können durchaus mehrere Applets parallel eingebunden sein, die untereinander kommunizieren. Genauso verhält es sich mit Servlets. Auch hier benötigen wir einen Container, der alle Servlets verwaltet. Dieser kann entweder in einem Web-Server eingebettet sein oder in einen Applikations-Server. Der Container leitet dann Anfragen an das Servlet weiter. Neben der Kommunikation nach außen verwaltet der Container den Lebenszyklus eines Servlets, genau wie ein Browser darüber wacht, ob das Applet gerade sichtbar ist oder nicht. Bei Servlets sieht ein solcher Vorgang wie folgt aus: Ein Client richtet eine HTTP-Anfrage an den Web-Server. Dieser bemerkt, dass es sich um ein Servlet handelt und gibt die Anfrage an den Container weiter. Dieser wiederum verwaltet alle Servlets und spricht genau das Servlet an, das der Benutzer nutzen wollte und übergibt Datenströme zur Ein- und Ausgabe. Das Servlet liest über den Eingabekanal optional Formularinhalte und generiert über den Ausgabestrom eine HTML-Seite, die der Container an den Client weiterreicht.

17.3.2 Web-Server mit Servlet-Funktionalität

Sun verzeichnet auf ihrer Web-Seite http://java.sun.com/products/servlet/industry.html eine Liste von Servlet-fähigen Servern. Ein Server ist genau dann Servlet-fähig, wenn er die Java-Servlet- und Java-Server-Pages (JSP)-Spezifikation erfüllt.

Die Servlet-Komponente kann integraler Bestandteil eines Servers oder auch ein Zusatz sein, der nachträglich zu installieren ist. Die wichtigsten Server sind:

Hier klicken, um das Bild zu Vergrößern Apache Tomcat Tomcat ist die offizielle Referenzimplementierung. Zum Testen von Servlets und JSP kann Tomcat sowohl als Stand-alone-Applikation eingesetzt oder als Ergänzung zum Apache Server eingebunden werden. Er ist ebenso wie der Apache-Server frei und findet sich unter http://jakarta.apache.org/tomcat. Wir nutzen die aktuelle Version 5 (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html) mit der Servlet 2.4- und JSP 2.0-Spezifikation.

Jetty Ein weiterer freier Open-Source-HTTP-Server und Servlet-Container mit guter Performance findet sich unter http://jetty.mortbay.org/jetty/.

Macromedia JRun JRun kann als Plugin in den Enterprise/FastTrack von Netscape, Microsoft IIS, Personal Web Server und weiteren, weniger verbreiteten Servern eingesetzt werden. Die Software ist kommerziell, eine eingeschränkte Version mit maximal fünf offenen Verbindungen ist frei. Mehr Informationen gibt es unter http://www.macromedia.com/software/jrun/.

New Atlanta's ServletExec ServletExec kann als Zusatz in die meisten Web-Server unter Solaris, Windows, MacOS, HP-UX und Linux eingebunden werden. Die Nutzung ist frei, Administrations-Tools sind jedoch kostenpflichtig. Die Firma New Atlanta hat ebenfalls einen freien Servlet-Debugger im Angebot, der sich in die meisten IDEs einklinken lässt, siehe unter: http://www.newatlanta.com/.

Der Web-Server von Sun (Sun's Java Web Server), eine Implementierung vollständig in Java, war der erste Servlet-Server. Mittlerweile hat Sun die Entwicklung eingestellt. Die Entwicklung wird unter dem Netscape/I-Planet-Server fortgesetzt. Weitere Informationen, die Sun zu Servlets bietet, findet sich unter http://java.sun.com/products/servlet/resources. html.

Rückblick: JSDK, JSWDK und Tomcat

Der Ursprung dynamischer Web-Seiten geht auf die Zeit zurück, als das JDK noch unter 1.0 ausgeliefert wurde. Sun nannte das Paket mit den Klassen und Programmen für die Servlet-Umgebung anfangs Java Servlet Development Kit (JSDK). Das Paket wurde bis zur Version 2.1 gepflegt. Da allerdings das alte JDK (Java Development Kit) in Java 2 Software Development Kit (J2SDK) umbenannt wurde, bestand eine Verwechslungsgefahr mit dem JSDK, so dass Sun das JSDK in Java Server Web Development Kit (JSWDK) umbenannte. Zusätzlich nahmen die Entwickler noch Java Server Pages auf. Das JSWDK begann in der Nummerierung wieder bei 1.0.

Nach langer interner Entwicklung hat Sun den Quellcode für das JSWDK der Apache-Gruppe übergeben, so dass die Implementierung jetzt Open Source ist. Die Apache-Gruppe entwickelte das JSWDK weiter und nannte es fortan Tomcat, das nun damit die einzig gültige Referenzimplementierung bildet. Weitere Freigaben werden offen sein und stehen unter dem Java Community Process. Damit endet die Produktlinie, und JSDK und JSWDK kommen ins Archiv. Der Name »Tomcat« wurde von Apache gewählt, da in frühen Entwicklungstagen Tomcat der interne Name für die Servlets bei Sun war. Erschwerend im Versions-Wirrwarr ist, dass die Spezifikation für Servlets und JSP andere Versionen als JSDK, JSWDK und jetzt Tomcat haben.

17.3.3 Tomcat

Jeder Server besitzt natürlich unterschiedliche Vorgehensweisen bei der Installation und beim Einbinden von Servlets und Verzeichnissen. Wir halten uns hier an die Implementierung von Tomcat in der Version 5.

Download und Installation

Der Tomcat-Server liegt unter http://www.apache.de/dist/jakarta/tomcat-5/v5.0.14-beta/bin/ als komprimiertes Archiv oder als .exe für Windows zum Laden bereit. Wir entscheiden uns für Windows und finden etwa das Installationsprogramm jakarta-tomcat-5.0.14.exe.

Während der Installation fragt Tomcat nach den Komponenten, die zu Installieren sind. Normal reicht hier aus. Full installiert einen Windows-Service, den es erlaubt, Tomcat direkt zu starten, wenn Windows startet. Auch wird der Quellcode mit installiert. Im nächsten Schritt ist ein Installationsverzeichnis zu wählen. Er schlägt bei einer deutschen Windows-Version C:\Programme\Apache Software Foundation\Tomcat 5.0 vor. Das soll O.K. sein. Der nächste Dialog fragt noch nach Port-Nummer, Benutzername und Passwort, aber der Dialog kann mit Next bestätigt werden. Falls ein Dialog mit einer JVM-Auswahl folgt, ist eine Laufzeitumgebung anzugeben und die Installation ist abgeschlossen. Ein Abschlussdialog gibt die Möglichkeit, Tomcat gleich zu starten. Warum nicht?

Ein Blick im Browser auf die lokale Adresse http://localhost:8080/ zeigt die Tomcat-Startseite. Hier finden sich Beispiele und die APIs für das Paket.

Starten und Enden

Im Startmenü (Start, Programme, Apache Tomcat 5.0) finden sich Eintrage auf weitere Programme und Webseiten. Dort kann Tomcat gestartet werden. Läuft Tomcat, so erzeugt er ein Icon in der Icon-Tray. Dort lässt sich Tomcat beenden.

Konfiguration

Nach der Installation von Tomcat liegen im Verzeichnis Tomcat 5.0 diverse Unterverzeichnisse. Im Unterverzeichnis conf/ liegt die XML-Datei server.xml, die eine wichtigste Konfigurationsdatei für den Server ist. Hier lässt sich beispielsweise der Port anpassen; ohne Veränderung der Voreinstellungen installiert sich der Web-Server auf dem lokalen Rechner auf Port 8080. Unter http://127.0.0.1:8080/admin/frameset.jsp lässt Tomcat weitere Konfigurationen zu - der Benutzername war »admin«, das Passowort ist leer. Interessant sind die Datenquellen für JDBC, genannt DataSource.