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 Webserver 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 Webbrowser 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 Webserver eingebettet sein oder in einen Applikationsserver. 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 Webserver. 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 Webserver mit Servlet-Funktionalität
Sun verzeichnet auf ihrer Webseite 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 aktuelle Spezifikation ist in der Version 2.3.
Die Servlets-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. |
|
|
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 Webserver 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/. |
|
|
Jetty
Ein weiterer freier Open-Source-HTTP-Server und Servlet-Container unter http:// jetty.mortbay.org/jetty/index.html. Gute Performance. |
Der Webserver 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 für dynamische Webseiten 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 Verwechselungsgefahr mit dem JSDK, sodass 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, sodass 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 das 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
|
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.0.4-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 Version 1.4 schon installiert sind. Wer mit der Version 1.2 arbeitet, sollte die nicht-Light Pakete installieren.
Nach der Installation liegt in einer deutschen Windows-Version – sofern nicht geändert – unter C:\Programme\Apache Tomcat 4.0 das Ergebnis der Installation. Im Unterverzeichnis bin/ befinden sich dann 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 Startmenü werden gleich Einträge zum Starten und Stoppen des Servers angeboten. Starten wir den Server, öffnet sich ein Fenster und es erscheint:
Starting service Tomcat-Standalone
Apache Tomcat/4.0.3
Starting service Tomcat-Apache
Apache Tomcat/4.0.3
| 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 Webserver 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.
|
