17.18 Das erste Servlet kompilieren und ausführen
 
Wir kommen nun noch einmal auf unser Eingangsbeispiel für ein Servlet zurück, welches eine einfache Ausgabe erzeugt.
Listing 17.19
FirstServlet.java
import java.io.*;
import javax.servlet.*;
public class FirstServlet extends GenericServlet
{
public void service( ServletRequest request,
ServletResponse response )
throws ServletException, IOException
{
PrintWriter out = response.getWriter();
out.println ( "'Chr! Schnarch! Razong! Chr! Chr! Rapüh!'"+
" (Disneys beste Comics, Band 5, S. 218)");
}
}
Alle Servlets implementieren die Schnittstelle javax.servlet.Servlet. Die Klasse GenericServlet implementiert diese Methoden und stellt uns eine einfache Klasse bereit, von der wir erben können. Verlangt der Client vom Webserver ein Servlet, so bildet der Servlet-Container ein Exemplar der Servlet-Klasse (in unserem Fall FirstServlet) und ruft nach der Initialisierung auf dem Objekt die Methode service() auf. Sie nimmt zwei Argumente an: ein ServletRequest und ein ServletResponse-Objekt.
Über request lassen sich alle Anfrageparameter erfragen. In der Unterklasse HTTPServlet–Request kommen zusätzlich Formularwerte oder ein HTTP-Anfragetyp dazu.
Mit response schicken wir die Daten, die zum Webclient zurückgehen, wie HTTP-Response (200, 404), Antwort-Header (Content-Type, Set-Cookie) zurück. Aber am Wichtigsten ist die Methode getWriter(), die uns eine Referenz auf ein Writer-Objekt liefert, damit wir die HTML-Elemente für die Seite abschicken. (Vorsicht! Ein 'System .' vor dem out ist diesmal nicht nötig – dieser Fehler schleicht sich schon mal ein.) Für Binärdaten können wir uns auch einen normalen 'OutputStream ' besorgen, damit wir zum Beispiel Bilder schicken können.
| Hinweis So gut wie alle Servlets erweitern die Unterklasse HttpServlet von GenericServlet Ein HttpServlet enthält wichtige Arbeitsfunktionen für das Protokoll HTTP. Eine Erweiterung von GenericServlet ist eher unüblich, es sei denn, Nicht-HTTP-Protokolle wie FTP werden angeboten.
|
17.18.1 Servlets kompilieren
Um Servlets zu übersetzen, müssen wir den CLASSPATH anpassen, sodass dieser auf das Jar-Archive servlet.jar zeigt. Das Archiv liegt bei Tomcat im Ordner common/lib bei.1
Bei der Enterprise-Version von Java (J2EE) ist die Bibliothek schon im Pfad eingebunden.
| Tipp Der Download für eine neue Version lohnt sich dennoch, da sich die Servlet-API und -Implementierung öfters ändert.
|
Servlet neu starten
Wenn wir das Servlet ändern und neu kompilieren, dann reicht es aus, den Inhalt im Browser zu aktualisieren (F5 im Internet Explorer). Ein vernünftiger Container sollte dann die Klasse automatisch neu laden. Was aber auf den ersten Blick so einfach aussieht, ist beim genaueren Hinsehen schon etwas komplizierter. Denn es ist nicht damit getan, nur Veränderungen zu überwachen. Das Problem ist, dass der Servlet-Container die geladenen Klassen wieder freigeben und neu laden muss.
Wer das automatische Neuladen vermeiden möchte, der muss bei Tomcat in der Konfigurationsdatei conf/server.xml den Eintrag reloadable="true" auf false setzen. Dadurch ergibt sich ein Geschwindigkeitsvorteil, da nicht vor jedem Starten geprüft werden muss, ob sich das Servlet geändert hat.
17.18.2 Wohin mit dem Servlet?
Das Übersetzen eines Servlets ist das kleinste Problem. Die Veröffentlichung macht da viel mehr Kopfschmerzen; wir benötigen einen Ort, an dem das Servlet abgelegt wird. Damit wir nicht erst lange in den Konfigurationsdateien editieren müssen, legen wir unser FirstServlet.class in das Verzeichnis, in dem auch die anderen Test-Servlets von Tomcat liegen. Sie sind dort mit Quellcode abgelegt und laden direkt zum Betrachten ein. Das Verzeichnis ist:
<jakarta-tomcat-Pfad>\webapps\examples\WEB-INF\classes
Um nun den Server zur Ausführung unseres FirstServlets zu bewegen, machen wir die Pfadangabe nicht in der URL, sondern wir schreiben:
http://localhost:8080/examples/servlet/FirstServlet
Diese Übersetzung von URL-Anfrage in die entsprechende Klasse nennt sich Servlet-Mapping und wird vom Servlet-Container übernommen. Nach der Servlet-Spezifikation lautet die URL pfad/servlet/klassenname. Der Server in der Testinstallation nimmt nur die Angabe examples zur Unterscheidung hinzu. Wo nun die Klassendateien wirklich liegen, ist ganz unterschiedlich. Das definiert eine Konfigurationsdatei.
1
Im Java-SDK 1.2 Beta waren die Klassen enthalten, doch sie wurden in der Finalversion wieder entfernt.
|
