17.16 Servlets 

Wir kommen nun noch einmal auf unser Eingangsbeispiel für ein Servlet zurück, welches eine einfache Ausgabe erzeugt. 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 Web-Server 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.

So gut wie alle Servlets erweitern eine Unterklasse von GenericServlet: HttpServlet. 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. Wir erweitern daher das FirstServlet zum SecondServlet.

Listing 17.19   FirstServlet.java

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class FirstServlet extends HttpServlet
{
 protected void doGet( HttpServletRequest req, HttpServletResponse res )
    throws ServletException, IOException
  {
    PrintWriter out = res.getWriter();

    out.println( "’Chr! Schnarch! Razong! Chr! Chr! Rapüh!’" );
    out.println( "(Disneys beste Comics, Band 5, S.  218)" );
  }
}

Über req lassen sich alle Anfrageparameter erfragen. In der Unterklasse HttpServletRequest kommen zusätzlich Formularwerte und ein HTTP-Anfragetyp dazu.

Mit res schicken wir die Daten, die zum Web-Client 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.

17.16.1 Servlets compilieren 

Um Servlets zu übersetzen, muss das Jar-Archiv servlet.jar im Pfad haben. Dazu können wir entweder den CLASSPATH anpassen oder das Archiv einfach in das jre/lib/ext-Verzeichnis des Java 2 SDKs kopieren; das Archiv liegt bei Tomcat im Ordner common/lib bei.¹  Bei der Enterprise-Version von Java (J2EE) ist die Bibliothek schon im Pfad eingebunden.

17.16.2 Wohin mit den Servlets: das classes-Verzeichnis 

Das Übersetzen eines Servlets ist das kleinste Problem. Die Veröffentlichung macht da mehr Kopfschmerzen. Erinnern wir uns an eine Webapplikation: Sie besteht aus einem Verzeichnis WEB-INF und mit optionalen Verzeichnissen classes und lib. Das Verzeichnis classses werden wir brauchen, denn dort müssen wir unser FirstServlet.class ablegen. Falls das Servlet in einem Paket liegt, so muss diese Paketstruktur natürlich auch auf die Verzeichnisstruktur abgebildet werden.

17.16.3 Servlets mit dem Sysdeo-Plugin unter Eclipse 

Arbeiten wir mit dem Sysdeo-Plugin, so müssen wir uns über diese Probleme gar nicht kümmern. Wie legen einfach das Servlet unter WEB-INF/src ab und es wird somit automatisch unter WEB-INF/classes compiliert.

17.16.4 Servlet-Mapping 

Um nun den Server zur Ausführung unserer Servlets zu bewegen, gibt es zwei Möglichkeiten:

Das Standard-Servlet-Mapping unter /servlet/

Ein eigener Deployment-Descriptor im Verzeichnis WEB-INF jeder Applikation

Standard-Servlet-Mapping

Im Fall des Standard-Servlet-Mappings wird ein Servlet zugänglich unter der URI servlet/SERVLETNAME. Um diese Möglichkeit einzuschalten, müssen wir die globale Konfigurationsdatei conf/web.xml modifizieren; wir müssen an zwei Stellen das so genannte Invoker-Servlet aktivieren.

Die erste Stelle ist

    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>

Und die zweite:

    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>

Stelt nun FirstServlet.class passend in WEB-INF/classes, dann lässt sich sich mit http://localhost:8080/jt/servlet/FirstServlet aufrufen.

Der Deployment-Descriptor web.xml

Soll der Invoker nicht zum Einsatz kommen, so müssen wir für jede Web-Applikation eine Datei web.xml im Verzeichnis WEB-INF anlegen. Die dient dazu, die Web-Applikation vollständig zu machen. Der Deployment-Descriptor zählt die Servlets auf und weist ihnen Pfade zu.

Listing 17.20   WEB-INF/web.xml

<?xml version="1.0" encoding="ISO-8859–1"?>

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd";>

<web-app>
 …
</web-app>

web.xml ist eine klassische XML-Datei, die nach einer festen DTD validiert wird. Die Angabe des DOCTYPE ist wichtig, sonst kann es Probleme mit unterschiedlichen Servlet-Containern geben. Im Wurzelelement <web-app> finden sich jetzt die spannenden Einträge, wie für unser Servlet FirstServlet.

  <servlet>
    <servlet-name>FirstServlet</servlet-name>
    <servlet-class>FirstServlet</servlet-class>
  </servlet>

Der erste Teil <servlet> listet Name und Klasse des Servlets auf. Jedes Servlet wird damit unter einem logischen Namen verfügbar gemacht und im nächsten Schritt auf ein Verzeichnis gemappt.

  <servlet-mapping>
    <servlet-name>FirstServlet</servlet-name>
    <url-pattern>/FirstServlet</url-pattern>
  </servlet-mapping>

Das Servlet mit dem Namen FirstServlet wird also unter /FirstServlet zu finden sein.

Damit ist alles komplett. Die Angabe von http://localhost:8080/jt/FirstServlet wird unser Servlet präsentieren und seine Ausgabe.

Für die Servlet 2.4 Spezifikation hat sich auch das XML-Format verändert. So ist dann zu schreiben:

<?xml version="1.0" encoding="iso-8859–1"?>
<web-app version="2.4" xmlns=http://java.sun.com/xml/ns/j2ee
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";>

  <servlet>
    <servlet-name>FirstServlet</servlet-name>
    <servlet-class>FirstServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>FirstServlet</servlet-name>
    <url-pattern>/FirstServlet</url-pattern>
  </servlet-mapping>
  </web-app>

Servlet neu starten

Wenn wir das Servlet ändern und neu compilieren, 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.

¹   Im Java-SDK 1.2 Beta waren die Klassen enthalten, doch sie wurden in der Finalversion wieder entfernt.