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. 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:
 |
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. Tomcat ist ebenso wie Apache frei und findet sich unter http://jakarta.apache.org/tomcat. |
Hier klicken, um das Bild zu Vergrößern
| |
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.
Container
Version
Servlet-Spezifikation
JSP-Spezifikation
| Tomcat
|
5
|
2.4
|
2.0
|
| Tomcat
|
4.0/4.1
|
2.3
|
1.2
|
| Tomcat
|
3.1
|
2.2
|
1.1
|
| JSWDK
|
1.0.1
|
2.1
|
1.0.1
|
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 4.
Download und Installation
Der Tomcat-Server liegt unter http://jakarta.apache.org/tomcat/ 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-4.1.18-LE-jdk14.exe. Die Endung »LE-jdk14« zeigt ein Archiv an, welches einen XML-Parser und weitere Bibliotheken nicht mehr erhält, da sie bei einer Installation von Java 2 SDK größer Version 1.4 schon installiert sind. Wer mit einer Java-Version 1.2 oder 1.3 arbeitet, sollte ein Nicht-Light-Paket installieren. Das Paket ist etwa 1,4 MB größer.
Während der Installation fragt Tomcat nach einem Installationsverzeichnis. Er schlägt bei einer deutschen Windows-Version C:\Programme\Apache Group\Tomcat 4.1 vor. Ein Dialog fragt noch nach Port-Nummer, Benutzername und Passwort, aber der Dialog kann mit Next bestätigt werden, und die Installation ist abgeschlossen.
Anschließend finden wir im Unterverzeichnis bin/ ausführbare Skripte zum Verwalten des Servers. Diese liegen zum einen als Batch-Datei für Windows vor und zum anderen als Shell-Skript für Unix. Gegenüber den älteren Versionen müssen keine Umgebungsvariablen eingestellt werden. Im Windows-Startmenü (Start, Programme, Apache Tomcat 4.1) werden gleich Einträge zum Starten und Stoppen des Servers angeboten. Starten wir den Server, öffnet sich ein Konsolen-Fenster und es erscheint:
03.03.2003 22:40:06 org.apache.commons.modeler.Registry loadRegistry
INFO: Loading registry information
03.03.2003 22:40:06 org.apache.commons.modeler.Registry getRegistry
INFO: Creating new Registry instance
03.03.2003 22:40:07 org.apache.commons.modeler.Registry getServer
INFO: Creating MBeanServer
03.03.2003 22:40:08 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/4.1.18-LE-jdk14
03.03.2003 22:40:12 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on port 8080
03.03.2003 22:40:16 org.apache.jk.common.ChannelSocket init
INFO: JK2: ajp13 listening on /0.0.0.0:8009
03.03.2003 22:40:16 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/20 config=C:\Programme\Apache Group\Tomcat 4.1\con
f\jk2.properties
| Hinweis Kommt unter Windows 98/Me die Fehlermeldung »Kein Speicherplatz mehr im Umgebungsbereich«, sollte bei den Dateien im Kontextmenü »Eigenschaften« unter »Speicher« und »Ursprünglicher Umgebungsspeicher« zum Beispiel der Wert 4096 eingetragen werden.
|
Im Unterverzeichnis conf/ liegen diverse XML-Dateien zur Konfiguration. Hier lässt sich beispielsweise der Port anpassen oder das Verzeichnis, in dem die Servlets beziehungsweise JSP-Seiten gesucht werden. Ohne Veränderung der Voreinstellungen installiert sich der Web-Server auf dem lokalen Rechner auf Port 8080.
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.
|
