WAR-Dateien und Installation

(Auszug aus "Java und XSLT" von Eric M. Burke)

Web-Application-Archive-, kurz WAR-Dateien, stellen im Servlet-Modell die elementaren Anwendungseinheiten dar. Sie ermöglichen Portabilität für eine Vielzahl von Servlet-Containern, unabhängig vom Hersteller. Sie sind einfach zu erzeugen, wenn man nur die Richtlinien für Datei- und Verzeichnisnamen berücksichtigt. Wenn Sie Tippfehler und falsch plazierte Dateien vermeiden, sollten Sie keinerlei Probleme mit WAR-Dateien haben.

WAR-Dateien

Die folgende Abbildung zeigt die Standardstruktur einer WAR-Datei. Da es sich bei WAR-Dateien lediglich um JAR-Dateien mit einer .war-Erweiterung handelt, kann man das jar-Kommando verwenden, um sie zu erzeugen.

Struktur einer WAR-Datei

Abbildung: Struktur einer WAR-Datei

Um eine WAR-Datei zu erzeugen, plazieren Sie Ihre Dateien in die Verzeichnisstruktur aus obiger Abbildung und rufen das folgende Kommando aus dem Verzeichnis, in dem index.html (index.html ist die »Homepage«, also die Startseite, einer Webanwendung) steht, auf:

jar -cvfM ../appname.war

Das Kommando plaziert die WAR-Datei ins übergeordnete Verzeichnis des aktuellen Arbeitsverzeichnisses. Der einfache Slash (/ ) funktioniert sowohl auf Windows- als auch auf Unix-Clients. Den Inhalt einer WAR-Datei kann man mit folgendem Kommando anzeigen:

jar -tvf appname.war

Das Inhaltsverzeichnis der WAR-Datei muß mit der Struktur in obiger Abbildung übereinstimmen.

Auf das oberste Verzeichnis der WAR-Datei kann öffentlich zugegriffen werden, es sollte Ihre JSP- und HTML-Dateien enthalten. Man kann aber weitere Unterverzeichnisse anlegen, auf die der Client ebenfalls zugreifen kann. So ist es z.B. üblich, ein images-Verzeichnis für Graphiken anzulegen.

Dagegen ist das Verzeichnis WEB-INF für Clients, die auf die Webanwendung zugreifen, gesperrt. Hier befinden sich der Anwendungsdeskriptor web.xml, das classes- und das lib-Verzeichnis. Wie in obiger Abbildung gezeigt wird, kann der ClassLoader auf das classes-Verzeichnis zugreifen, und alle JAR-Dateien im lib-Verzeichnis sind für Ihren Code ebenfalls verfügbar. So können auf einfache Weise Bibliotheken von Drittanbietern mit Ihrer Webanwendung eingesetzt werden. Beliebige weitere Verzeichnisse können unter andere_verzeichnisse abgelegt werden. Sie sind für die Clients ebenfalls nicht sichtbar, da es sich um Unterverzeichnisse von WEB-INF handelt. Obwohl Clients keinen direkten Zugriff auf diese Dateien erhalten, kann Ihr Servlet selbstverständlich darauf zugreifen oder deren Inhalt übermitteln.

Der Anwendungsdeskriptor

Der Anwendungsdeskriptor heißt immer web.xml und muß sich direkt im Verzeichnis WEB-INF der Webanwendung befinden. Er stellt die gesamten Konfigurationsinformationen der Webanwendung für den Servlet-Container bereit. Dies umfaßt Sicherheitsattribute, Aliase für Servlets und andere Ressourcen, Initialisierungsparameter und Icons für integrierte Entwicklungsumgebungen (IDEs). Für unsere Zwecke ist eine kleine Untermenge dieser Funktionalitäten ausreichend. Für das SplashScreenServlet müssen wir die Java-Klasse des Servlets, einen Alias für das Servlet und eine URL-Zuordnung auflisten. Der komplette Anwendungsdeskriptor für SplashScreenServlet wird im folgenden Beispiel dargestellt.

Beispiel: web.xml für SplashScreenServlet.java

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
<web-app>
    <servlet>
        <!-- definiere einen Alias für das Servlet -->
        <servlet-name>splashScreen</servlet-name>
        <servlet-class>chap6.SplashScreenServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <!-- Ordne dem Servlet ein URL-Muster zu -->
        <servlet-name>splashScreen</servlet-name>
        <url-pattern>/splash/*</url-pattern>
    </servlet-mapping>
</web-app>

Die DOCTYPE-Deklaration wird in jedem Anwendungsdeskriptor benötigt und sieht wie im Beispiel web.xml für SplashScreenServlet.java aus. Beachten Sie, daß neuere Versionen der Servlet-Spezifikation, wie z.B. die Version 2.3, eine abweichende Versionsnummer im Anwendungsdeskriptor benutzen. Solange Sie keine Funktionalitäten der Version 2.3 benutzen, sollten Sie bei 2.2 bleiben, um mit möglichst vielen Servlet-Containern kompatibel zu bleiben.

Eine Servlet-Definition beinhaltet die voll qualifizierten Paket- und Klassennamen und einen Namen für das Servlet. Wenn ein anderer Teil des Anwendungsdeskriptors dieses bestimmte Servlet ansprechen will, verwendet er den hier spezifizierten Namen:

<servlet>
  <servlet-name>splashScreen</servlet-name>
  <servlet-class>chap6.SplashScreenServlet</servlet-class>
</servlet>

Wie das Beispiel web.xml für SplashScreenServlet.java zeigt, wird dieser Name bei der Servlet-Zuordnung benutzt, um ein URL-Muster mit diesem speziellen Servlet zu verknüpfen. Dieses Muster taucht in der Adresse auf, die ein Nutzer in seinem Browser eingibt, um auf das Servlet zuzugreifen. In diesem Fall ist die URL von SplashScreenServlet die folgende:

"http://hostname:port/chap6/splash"

Diese Form entspricht dem Tomcat-Standard und hat die folgenden Komponenten:

hostname:port

Typischerweise localhost:8080, obwohl Tomcat für jede beliebige Portnummer konfiguriert werden kann.

chap6

Der Name Ihrer Webanwendung, welche in diesem Beispiel in chap6.war definiert wird.

splash

Teil des URL-Musters für das Servlet

Platzhalter stehen für jeden beliebigen Text im URL-Muster. Da unser Anwendungsdeskriptor den String /splash/* als Muster hat, wird jede der folgenden URLs SplashScreenServlet aktivieren:

  • "http://localhost:8080/chap6/splash/"
  • "http://localhost:8080/chap6/splash/irgendwas.html"
  • "http://localhost:8080/chap6/splash/a/b/c"

Der Einsatz von SplashScreenServlet unter Tomcat

Die folgenden einfachen Schritte sind nötig, um SplashScreenServlet zum Laufen zu bekommen. Kompilieren des Programmcodes, Erstellen des Anwendungsdeskriptors aus dem Beispiel web.xml für SplashScreenServlet.java und Erzeugen der WAR-Datei mit jar. Der Inhalt der WAR-Datei für dieses Servlet ist in folgender Abbildung zu sehen.

WAR-Datei von SplashScreenServlet

Abbildung: WAR-Datei von SplashScreenServlet

Nachdem Sie chap6.war erzeugt haben, stellen Sie bitte mit jar -tvf chap6.war sicher, daß der Inhalt richtig strukturiert ist. Im letzten Schritt wird die komplette WAR-Datei in das Verzeichnis webapps von Tomcat kopiert.

Hinweis:
Wenn eine WAR-Datei in das webapps-Verzeichnis kopiert wird, während Tomcat läuft, wird sie nicht aktiv. Starten Sie Tomcat neu, um die Webanwendung zu nutzen.

Nachdem Sie die WAR-Datei kopiert haben, führen Sie startup.bat bzw. startup.sh im bin-Verzeichnis von Tomcat aus, und geben Sie die URL "http://localhost:8080/chap6/splash" in einem Webbrowser ein. Falls Sie Fehlermeldungen sehen, überprüfen Sie die Umgebungsvariablen JAVA_HOME und TOMCAT_HOME. Desweiteren können Sie im Verzeichnis webapps von Tomcat prüfen, ob die WAR-Datei korrekt entpackt wurde. Wenn eine Webanwendung das erste Mal aufgerufen wird, entpackt Tomcat die WAR-Datei im Verzeichnis webapps. Dort sollten Sie sowohl chap6.war als auch das Verzeichnis chap6 vorfinden.

Falls nicht, lesen Sie die Tomcat-Dokumentation, überprüfen Sie Ihren Anwendungsdeskriptor, und testen Sie die Beispiel-Servlets von Tomcat. Dazu starten Sie Tomcat und geben "http://localhost:8080" in Ihrem Browser ein. Wenn selbst das nicht funktioniert, gibt es grundlegende Probleme mit Ihrer Tomcat-Installation.

Wichtige Aspekte der Servlet-API

Wir werden noch komplexere Servlets in diesem Buch kennenlernen, wobei wir dabei immer versuchen werden, spezielle Servlet-Techniken auszuklammern und uns auf die Anwendung von XML und XSLT zu konzentrieren, um den Inhalt Ihrer Webanwendungen zu generieren. Um dies zu tun, müssen wir uns einige der gebräuchlichen Klassen des Servlet-Pakets genauer anschauen.

Die Klasse javax.servlet.ServletConfig stellt die Initialisierungsparameter eines Servlets für dessen Start bereit. Jedes Servlet besitzt die folgende Methode, die einmal aufgerufen wird, wenn das Servlet das erste Mal initialisiert wird:

public void init(ServletConfig config) throws ServletException

Das Objekt ServletConfig stellt String-Paare mit Namen und Wert zur Verfügung, die für die Konfiguration des Servlets benutzt werden, so daß die Werte nicht fest in den Anwendungscode programmiert werden müssen:

String xmlLocation = config.getInitParameter("xmlLocation");

Da xmlLocation ein Initialisierungsparameter aus dem XML-Anwendungsdeskriptor ist, muß sein Wert nicht in Ihre Anwendung programmiert werden. Weitere Beispiele finden Sie im Abschnitt Stylesheets mit Initialisierungsparametern lokalisieren.

Eine weitere wichtige Klasse ist javax.servlet.ServletContext. Diese Klasse kann viel mehr als ServletConfig, und eine Instanz von ihr kann in einer ganzen Gruppe von Servlets verwendet werden. Mit ServletConfig kann eine Referenz auf einen ServletContext erzeugt werden:

// config ist eine Instanz von ServletConfig
ServletContext ctx = config.getServletContext( );

Wir werden noch auf die Fähigkeit von ServletContext zurückkommen, Ressourcen auf portable Weise zu lokalisieren. Wahrscheinlich kennen Sie die Methoden getResource( ) und getResourceAsStream( ) von java.lang.Class. Diese Methoden erlauben es, Dateien in Abhängigkeit vom systemweiten CLASSPATH zu lokalisieren.

ServletContext stellt die Methoden getResource( ) und getResourceAsStream( ) bereit, die aber nicht auf einer Auswertung des CLASSPATH, sondern dem Ort der aktuellen Webanwendung basieren. Zum Beispiel kann mit

context.getResource("/WEB-INF/stylesheets/home.xslt")

ein Stylesheet aus der aktuellen WAR-Datei gelesen werden. Unabhängig davon, wo Tomcat installiert ist, wird dieser Ansatz das Stylesheet immer finden, ohne einen Pfad wie C:\path\... fest einzuprogrammieren.

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Java & XSLT bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2002 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Java und XSLT" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de