Inhalt

1. Einsatzmöglichkeiten des TOMCAT-Server

2. Installation des Tomcat als eigenständigen Web-Server

3. Grundlegende Einstellungen

4. Konfiguration als Servlet-Container
   und Kommunikation mit dem Apache Web-Server

1. Apache vorbereiten

2. Das JK-Modul

3. out-of-process-Lösung

1. Worker definieren

2. Änderungen der Konfiguration des Apache ('httpd.conf')

3. Tomcat auf mehreren Rechnern

4. in-process-Lösung

5. Quellen

I.

Wie kann man den Tomcat-Server einsetzen?

Der Tomcat-Server wird wie der Apache Web-Server innerhalb des Jakarta-Projektes weiterentwickelt. Der Tomcat ist ein Web-Server und Servlet-Container.

Die Tomcat-Version 3.2.1, welche hier verwendet wird, unterstützt die Servlet Spezifikation 2.2 und JSP 1.1. Es wird weiterhin an der Stabilität und Performance der 3er Version gearbeitet, währenddessen auch schon eine Tomcat Version 4 und ein weiteres Projekt mit Namen Catalina existiert, beide allerdings noch in einer Alpha-Version. Catalina unterstützt heute schon die Servlet Spezifikation 2.3 und JSP 1.2.

Tomcat soll aber nicht als eigenständiger Web-Server mit Servlet-Container Funktionalität eingesetzt werden, sondern seine Servlet-Container Dienste anderen Web-Servern zu Verfügung stellen.

Man hat also mehrere Möglichkeiten den Tomcat einzusetzen:

1. Als stand-alone Web-Server mit Servlet-Container Funktionalität

   Hierbei bearbeitet der Tomcat auch HTTP-Anfragen und liefert statische Dokumente aus.
   Dies ist die Standardkonfiguration, man sollte dies aber nur zum Testen und Entwickeln
   von Web-Applikationen benutzen, da traditionelle Web- Server (wie derApache)
   wesentliche Vorteile bieten, wie z.B. Schnelligkeit, flexiblere Einstellmöglichkeiten.

   
   

2. Als in-process Lösung

   Hier arbeitet Tomcat mit einem anderen Web-Server zusammen. Die Verbindung erfolgt durch ein Web-Server-plugin über das Java-Native-Interface (JNI).

   Das Plugin öffnet eine Java Virtual Machine (JVM) im Adressraum des Web-Servers und startet dort den Servlet-Container.

   Vorteile:

   hohe Performance (vorallem bei Multi-Thread fähigen Web-Servern
   wie dem Apache 2 ) bei der Kommunikation von Web-Server und Tomcat.

   Nachteile:

   kaum Skalierbar, nicht so robust (da beide in einem Prozess laufen)

2. Als out-of-process Lösung

   Hier wird die Verbindung durch ein Web-Server-plugin über TCP/IP, hier das Apache JServ Protocol (AJP) , hergestellt. Die JVM des Tomcat läuft also nicht mehr im selben Prozess wie der Web-Server. Durch Verwendung von TCP/IP kann die Kommunikation zwischen Web-Server und Tomcat auch über getrennte Rechner laufen.

   Vorteile:

   gut Skalierbar und hohe Stabilität, da man mehrere Tomcat auf verschiedenen
   Rechnern laufen lassen kann.

   Nachteile:

   Antwortzeiten etwas länger als bei der in-process Lösung.

II.

Installation des Tomcat als eigenständigen Web-Server

Zunächst installieren wir den Tomcat als stand-alone Web-Server.

Eigentlich muss man den Tomcat in der Binärdistribution nur entpacken, er ist dann als stand-alone Web-Server vorkonfiguriert.

Da der Tomcat komplett in Java implementiert ist, werden beim Übersetzen des Quellcodes keine Anpassungen an die System-Plattform vorgenommen. Deshalb ist die Binärdistribution zu bevorzugen.

Entpacken der Binärdistribution:

tar -xvzf jakarta-tomcat-3.2.1.tar.gz

Es wird ein Unterverzeichnis 'jakarta-tomcat-3.2.1' erzeugt, in das alles weitere entpackt wird.

Wichtige Unterverzeichnisse :

Voraussetzungen zumBetrieb ist JDK 1.1, empohlen ist eine JAVA 2 Plattform in der Version 1.2.2. Ausserdem sollten folgende Umgebungsvariablen gesetzt sein:

export JAVA_HOME={Pfad zur java-Installation}

export TOMCAT_HOME={Pfad zur Tomcat-Installation}

Das Start-Skript unter Unix-Systemen versucht diese Umgebungsvariablen selber zu setzen, das funktioniert aber für TOMCAT_HOME nur, wenn das Skript auch aus dem Installations-Verzeichnis gestartet wurde.

Um den Tomcat zu starten und zu stoppen benutzt man folgende Skripte aus dem Tomcat-Verzeichnis heraus:

bin/startup.sh

bin/shutdown.sh

Diese Skripte rufen das tomcat.sh Skript auf, welches alle wichtigen Umgebungs-variablen setzt(z.B. CLASSPATH).

Optionen des Skripts tomcat.sh

III.

Grundlegende Einstellungen

Alle Konfigurationsdateien liegen im Verzeichnis conf. Die wichtigsten Konfigurationsdateien sind 'server.xml' und 'web.xml'.

web.xml

Basis Deployment-Deskriptor für alle Webapplikationen

Jede Web-Applikation hat ausserdem sein eigenes web.xml-File, indem aber nur der Standard-Deployment-Deskriptor ergänzt oder überschrieben wird.

Die Standardkonfiguration gibt an:

· Default-Servlet

· virtuelles Servlet-Verzeichnis. Mapping auf /servlet/*

· Integration von Jasper für alle JSP-Seiten

· Standard Time-Out-Wert für Sitzungen (30 Minuten)

· Mappings, die Dateiendungen und zugehörigen MIME-Type beschreiben

· Standard Welcome-Files (index.jsp, index.html, index.htm)

server.xml

Server Konfiguration und Deployment der Webapplikationen

ContextInterceptor

Standardmässig werden alle Applikation aus dem Ordner webapps beim Start des Servers automatisch geladen. Dies erfolgt über folgendes TAG:

<ContextInterceptor className="org.apache.tomcat.context.AutoSetup" />

Es ist sinnvoll dies im realen Betrieb abzuschalten, indem man diesen Tag entfernt (bzw. auskommentiert).

Connector

Standardmässig ist der HttpConnector aktiviert.

Dies erfolgt durch folgenden Eintrag:

<Connector className="org.apache.tomcat.service.PoolTcpConnector">
    <Parameter name="handler"
               value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
    <Parameter name="port"
               value="8052"/>
</Connector>

Hier kann man auch den Port ändern auf dem der Server Anfragen erwartet. Wenn man den Tomcat aber nicht gerade dazu benutzt HttpAnfragen zu bearbeiten, sollte man auch diesen Eintrag entfernen.

Weitere Connectoren braucht man für die Kommunikation mit dem Web-Server.

Standardmässig ist der folgende aktiviert:

<Connector className="org.apache.tomcat.service.PoolTcpConnector">
    <Parameter name="handler"
               value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
    <Parameter name="port"
               value="8007"/>
</Connector>

Hiermit sind Verbindungen über das Apache JServ Protokoll Version 12 möglich.

Um auch das ajp 13 nutzen zu können, muss noch folgender Eintrag gemacht werden:

<Connector className="org.apache.tomcat.service.PoolTcpConnector">
    <Parameter name="handler"
               value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/>
    <Parameter name="port"
               value="8009"/>
</Connector>

Hier kann man auch wieder jeweils den Port einstellen.

Context

Wenn der AutoDeployer abgeschaltet ist, oder man Webapplikationen einsetzen möchte, die nicht im webapps-Ordner liegen, muss man für jede Webapplikation einen eigenen Context einführen.

<Context path="/katalog"
         docBase="shopapps/katalog"
         debug="0"
         reloadable="false"
         trusted="false" >
</Context>

path : logisches Wurzelverzeichnis der Applikation

docBase : reales Verzeichnis der Applikation

relativer Pfad zum tomcat_home-Verzeichnis oder absoluter Pfad

debug : Debug Stufe

reload : true :Applikation wird bei Veränderung automatisch neu geladen

false : Applikation wird nicht automatisch neu geladen

trusted : Eine Web-Applikation hat Zugriff auf ein internes Objekt von Tomcat,

wenn der Wert auf true gesetzt ist

Virtuelle Hosts

Die Einzelnen <Context>-Elemente stehen unterhalb von einem <Host>-Element.

<Host name="katalog.shop.fhw" >
    <Context path=""
             docBase="shopapps/katalog" />
    <Context path=""
             docBase="..." />
   .....
</Host>

IV.

Konfiguration als Servlet-Container

und Kommunikation mit dem Apache Web-Server

1. Apache vorbereiten

Da der Apache über ein Modul mit dem Tomcat kommuniziert, muss das Modul

'mod_so' im Apache integriert sein. Dies ist das einzige Modul, das mitkompiliert werden muss. Es ist für die Einbindung weiterer Module zuständig.

Man könnte den Apache also folgendermassen installieren:

Nach dem Entpacken der Apache-Source Distribution, in das entstandene Verzeichnis wechseln und das configure-Skript aufrufen:

./configure --prefix=/local/i564/liste_v/apache/ --enable-module=speling

--enable-module=info --enable-module=so

make

make install

Natürlich muss hier das Verzeichnis /local/i564/liste_v/apache/ bereits existieren,

bevor make install ausgeführt wird.

2. Das Jk-Modul

Um mit dem Tomcat zu kommunizieren benötigt man ein Web-Server-plugin.

Neben dem älteren JServ-Modul, gibt es auch das neuere Jk-Modul, welches hier

weiterhin verwendet wird. Dies muss zunächst kompiliert werden.

Dazu verwendet man das PERL 5-Skript apxs, welches sich im bin-Verzeichnis

des Apache finden lässt. Dad JK-Modul ist in C implementiert. Den Quellcode findet man in der Source-Distribution des Tomcat (jakarta-tomcat-3.2.1-src.tar.gz) .

Nach dem Entpacken wechselt man ins Verzeichnis 'jakarta-tomcat-3.2.1-src/src/native/apache1.3' , kopiert das Perl-Skript (apxs) hinein und ruft es

folgendermassen auf:

apxs -o mod_jk.so -I../jk -I/usr/lib/java/include

-I/usr/lib/java/include/linux -c *.c ../jk/*.c

gcc -shared -o mod_jk.so *.o

Jetzt muss noch das entstandene Modul 'mod_jk.so' ins Apache-Verzeichnis

.../apache/libexec/

kopiert werden.

3. out-of-process Lösung

1. Worker definieren

Ein Worker ist die abstrakte Bezeichnung einer Servlet-Container Instanz, die mit ihrer Applikation, die an sie gerichtete Anfrage bearbeiten kann.

Ein Worker wird definiert durch:

· einen Alias-Namen

· seinen Server

· das verwendete Protokoll

· die Port-Nummer

Eine Beispielkonfiguration befindet sich in der Datei workers.properties.

Eine Definition sieht so aus: worker.<worker-name>.<eigenschaft>=<wert>

oder global: worker.<eigenschaft>=<wert>

Der worker-name ist beliebig.

Eigenschaft	Wert
server	Servername oder IP-Adresse, Beispiel:localhost
type (das Protokoll)	ajp12, ajp13 : reale Protokolle lb : (loadbalancer) jni : java native interface - (in-process-Konfiguration)
port	8007, 8009 (beliebig)
lbfactor	Zahl>0
cachesize	Anzahl gleichzeitiger Verbindungen : nur ajp13
balanced-workers	reale worker-namen : nur lb
list	worker die aktiviert werden sollen : nur global

Nur global aktivierte worker (->worker.list=...) können eingesetzt werden.

Beispiel (aus der Standardkonfiguration von workers.properties):

aktive, einsetzbare worker

worker.list=ajp12, ajp13

Der Worker ajp12:

worker.ajp12.port=8007

worker.ajp12.host=localhost

worker.ajp12.type=ajp12

worker.ajp12.lbfactor=1

Der Worker ajp13:

worker.ajp13.port=8009

worker.ajp13.host=localhost

worker.ajp13.type=ajp13

worker.ajp13.lbfactor=1

Der nicht reale Worker loadbalancer.

Er ist nicht einsetzbar, solange er nicht in der worker.list steht:

worker.loadbalancer.type=lb

worker.loadbalancer.balanced_workers=ajp12, ajp13

Ein Worker vom Typ lb verteilt die Last auf die 'balanced-workers' gemäss der Eigenschaft 'lbfactor' der einzelnen realen worker. Dieser loadbalancer 'merkt' auch, wenn ein worker nicht mehr Einsatzbereit ist. Fortan werden nur noch die anderen angesprochen.

Die so definierten worker können jetzt in der Apache-Konfiguration benutzt werden.

Man verknüpft nun spezielle Web-Anwendungen mit einem worker, der diese dann bearbeitet.

1. Änderungen der Konfiguration des Apache ('httpd.conf')

Es ist am besten den Teil der Apache-Konfiguration,der sich mit der Konfiguration des JK-Moduls beschäftigt, in einer eigenen Datei zu halten und diese dann mittels der Direktive Include in die httpd.conf einzubinden.

Der Tomcat-Server erstellt bei jedem Start so eine Datei: mod_jk.conf-auto

In dieser Datei sind die wichtigsten Einstellungen schon gemacht, und sie wird sogar automatisch aktuallisiert, sobald man den Tomcat neu startet.Sie hat aber einen entscheidenden Nachteil, man kann nicht die Worker frei vergeben. Vielmehr wird ein Worker mit dem Namen ajp12 vorausgesetzt, der in der workerdatei definiert sein muss. Dies ist der einzige Worker der benutzt wird.

Diese Datei bindet man dann so in die httpd.conf ein:

Include {TOMCAT_HOME}/conf/mod_jk.conf-auto

In dieser Datei müssen folgende Einträge stehen:

Laden des JK-Moduls:

LoadModule jk_module libexec/mod_jk.so

JkWorkerFile Pfad zu 'workers.properties'

JkLogFile Pfad zu mod_jk.log

JkLogLevel debug, info, error oder emerg

Welche URI-Muster sollen von welchem worker bearbeitet werden?

JkMount <uri-muster> <worker>

Beispiel:

JkMount /*.jsp ajp12

JkMount /servlet/* ajp12

Alle Dateien mit dfer Endung *.jsp und alle URI's, die mit /servlet/ beginnen werden vom worker mit dem Namen ajp12 bearbeitet.

Vorrausetzungen dafür sind, dass ein worker mit diesem Namen existiert, d.h. in der workers.properties definiert wurde, und dass ein Connector vom Typ dieses workers (hier der AJP12-Connector) in der server.xml aufgenommen wurde.

Für jeden Context in server.xml muss auch ein Eintrag in die httpd.conf:

Der Apache muss wissen, wo die Web-Anwendung ist:

Alias /katalog "/opt/tomcat/shopapps/katalog"
<Directory "/opt/tomcat/shopapps/katalog">
    Options Indexes FollowSymLinks
</Directory>

Workerzuordnung

JkMount /katalog/*.jsp ajp12

JkMount /katalog/servlet/* ajp12

Diese Ordner sollen besonders geschützt werden

<Location "/bestellen/WEB-INF/">
    Allow Override None
    deny from all
</Location>
<Location "/bestellen/META-INF/">
    Allow Override None
    deny from all
</Location>

Mit der Standardkonfiguration des Tomcat kann man also ohne weiteres den Servlet-Container mit Apache auf einem Rechner benutzen.

Vorausgesetzt der Apache ist mit dem Modul so installiert und das Modul jk befindet sich im Verzeichnis libexec, zudem wurde der Tomcat erfolgreich entpackt, muss

nur, nach einem ersten Start des Tomcat(, damit die Datei mod_jk.conf-auto erzeugt wird), die beschriebene Include Anweisung in die httpd.conf eingefügt werden.

3. Tomcat auf mehreren Rechnern

Es empfiehlt sich bei einer realen Konfiguration mit einem Apache und mehreren Tomcat auf verschiedenen Rechnern, die Dateien workers.properties und mod_jk.conf(-auto) ins Apache conf-Verzeichnis zu kopieren und dort anzupassen.

Bei der Workerdefinition muss nun nur der Servername angepasst werden. Ansonsten müssen nur die Pfade angepasst werden.

In der httpd.conf, der Pfad in der Include-Anweisung auf die Datei mod_jk.conf

(da diese jetzt nicht mehr automatisch generiert wird, empfiehlt es sich das auto zu löschen).

In der workers.properties, die Pfade von JkWorkerFile und JkLogFile.

3. in-process Lösung

Für eine in-process Lösung betreibt man den Web-Server und den Tomcat auf demselben Rechner, und aktiviert nur den worker vom Typ jni. Dieser kann dann genauso benutzt werden wie zuvor beschrieben.

V.

Quellen

Die Binär- sowie die Sourcedistribution des Tomcat einschliesslich des JkModuls:

jakarta-tomcat-3.2.1.tar.gz

jakarta-tomcat-3.2.1-src.tar.gz

sind unter http://www.jakarta.apache.org/builds/tomcat verfügbar.

Der Quellcode des Apache Web-Servers:

apache_1.3.19.tar.gz

unter http://www.apache.org.

Der Vortrag entstand mit Hilfe des Buches Turau 2001 und der ausführlichen Dokumentation des Tomcat (vorallem: Tomcat - A Minimalistic User's Guide von Gal Shachor).

Dieser Vortrag als StarOffice-Version(tomcat.sdw) (~85kb)
und als Word97/2000-Version(tomcat.doc) (~53kb).
Diese Ausarbeitung wurde mit StarOffice angefertigt, deshalb ist diese Version auch zu
bevorzugen. In der MS-Word-Version sind einige Formatierungs-Fehler.
Folien als StarOffice-Präsentation(tomcat.sdd) (~56kb).
Das Modul JK(mod_jk.so)für Linux (~105kb).
Getestet unter Suse Linux 7.1 .