17.16 Servlets
 
Wir kommen nun noch einmal auf unser Eingangsbeispiel für ein Servlet zurück, das 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.20
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 HttpServlet-Request kommen noch Formularwerte und ein HTTP-Anfragetyp hinzu.
Mit res schicken wir die Daten, die zum Web-Client zurückgehen, wie HTTP-Response (200, 404), und Antwort-Header (Content-Type, Set-Cookie) zurück. Am wichtigsten ist aber 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.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 der Java SE kopieren; das Archiv liegt bei Tomcat im Ordner common/lib bei.1
Bei der Enterprise-Version von Java (Java EE) ist die Bibliothek schon im Pfad eingebunden.
Tipp Das Einbinden der Tomcat-Version von servlet.jar lohnt sich dennoch, da sich die Servlet-API und -Implementierung öfters ändern und bei der Java EE nicht unbedingt die neueste Version integriert sein muss.
|
17.16.2 Die Servlets in das classes-Verzeichnis
 
Das Übersetzen eines Servlets ist das geringste Problem. Die Veröffentlichung bereitet mehr Kopfschmerzen. Erinnern wir uns an eine Webapplikation: sie besteht aus einem Verzeichnis WEB-INF mit den optionalen Verzeichnissen classes und lib. Wir werden das Verzeichnis classes benötigen, da wir dort unser FirstServlet.class ablegen müssen. Falls das Servlet in einem Paket liegt, muss diese Paketstruktur natürlich auch auf die Verzeichnisstruktur abgebildet werden.
Beispiel Arbeiten wir mit einem Eclipse-Plugin, müssen wir uns um diese Probleme 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.3 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 und 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>
Stellt nun FirstServlet.class passend in WEB-INF/classes, lässt sich Erstere mit http://localhost:8080/jt/servlet/FirstServlet aufrufen.
Der Deployment-Descriptor web.xml
Soll der Invoker nicht zum Einsatz kommen, müssen wir für jede Web-Applikation eine Datei web.xml im Verzeichnis WEB-INF anlegen. Die dient dazu, die Web-Applikation vervollständigen. Der Deployment-Descriptor zählt die Servlets auf und weist ihnen Pfade zu.
Listing 17.21
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 und seine Ausgabe präsentieren.
Für die Servlet 2.4 Spezifikation hat sich auch das XML-Format verändert. So ist hier 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, reicht es aus, den Inhalt im Browser zu aktualisieren (F5 im Internet Explorer). Ein vernünftiger Container sollte die Klasse dann automatisch neu laden. Was aber auf den ersten Blick so harmlos aussieht, ist bei genauerem Hinsehen schon etwas komplizierter, weil es nicht damit getan ist, nur Veränderungen zu überwachen. Das Problem besteht darin, 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, weil nicht vor jedem Start geprüft werden muss, ob sich das Servlet geändert hat.
1 Im Java-SDK 1.2 Beta waren die Klassen enthalten, doch sie wurden in der Finalversion wieder entfernt.
|