<jsptutorial />

Tomcat als lokaler Testserver


Hinweis

Zusätzlich zu diesem Kapitel gibt es noch Informationen
  1. zu Tomcat Valves im Kapitel Servlet-Filter,
  2. zu möglichen Encoding-Einstellungen im Tomcat im Kapitel Internationalisierung und
  3. zum Aufbau des Verzeichnisbaums im Kapitel Verzeichnisstruktur von Java-Webanwendungen
Da wir selbst auf Tomcat oder Glassfish als Servlet-Container setzen, sind zudem kleinere Anmerkungen zu diesen Containern vereinzelt auch im Rest des Tutorials zu finden.


Um mit JSPs arbeiten zu können, benötigen wir einen Servlet-Container und eine JSP-Engine, die die Transformation der JSPs in Servlets vornimmt. Selbstverständlich gibt es da eine Reihe unterschiedlicher Hersteller, in diesem Tutorial nutzen wir jedoch als Arbeitsumgebung den Servlet-Container Tomcat der Apache Software Foundation.
Dafür sprechen aus unserer Sicht mehrere Gründe:

  1. Der Tomcat ist die offizielle Referenz-Implementierung eines Servlet-Containers. Als solcher ist garantiert, dass er sich konform zur JSP- und Servlet-Spezifikation verhält.

  2. Tomcat ist der verbreitetste Servlet-Container. Er wird auf einem Viertel aller Produktionssysteme eingesetzt. (link)

  3. Tomcat ist für eine Reihe von Plattformen verfügbar. Er ist komplett in Java geschrieben (was aber für nahezu alle Servlet-Container gilt), und die Startskripte sind für Windows- und Unix vorkonfiguriert. Die Installation gestaltet sich daher auf den verbreiteten Arbeitsplatz-Betriebssystemen sehr einfach.

  4. Tomcat ist Freie Software. Somit liegt der komplette Source-Code vor, und man kann - wenn man will - die Vorgänge im Inneren besser nachvollziehen. Das ist freilich nicht so trivial und wird in der Praxis wohl von den wenigsten Entwicklerinnen gemacht.
    Neben Tomcat existiert mit "jetty" noch mindestens ein weiterer freier Servlet Container (link).

  5. Tomcat ist kostenlos von der Apache-Website herunterladbar. Auch hier sei fairerweise vermerkt, dass kommerzielle Hersteller häufig kostenlose Developer-Editionen ihrer Produkte anbieten.

Keiner der Gründe (außer vielleicht dem ersten) würde alleine schon für Tomcat sprechen. Aber die Kombination macht ihn für die Zwecke unseres Tutorials zur idealen Arbeitsplattform. Letztlich können Sie aber natürlich auch andere Container einsetzen. Aufgrund der Standardisierung der JSP- und Servlet-Spezifikationen ist gewährleistet, dass die Beispiele des Tutorials auch auf anderen Containern funktionieren. Einige wenige Beispiele für Container-spezifisches Verhalten (Sicherheits-Konfigurationen, transformierter Java-Code einer JSP u.ä.) sind allerdings speziell auf Tomcat zugeschnitten.

Zum SeitenanfangZum Seitenanfang

Installation von Tomcat als Standalone-Engine

Im Folgenden werden die Installation unter Windows und die unter einem Unix-System (hier Linux, aber das ist letztlich egal) beschrieben. Interessanterweise enthalten alle Downloads die gleichen Dateien. So entpackt die Installationsroutine der Datei "jakarta-tomcat-5.0.29.exe" auch diverse Shellskripte, und umgekehrt findet man nach dem Entpacken der Datei "jakarta-tomcat-5.0.29.tar.gz" im "bin"-Verzeichnis die Datei "tomcat.exe". Insofern hätte eigentlich eine Beschreibung des Installationsprozesses gereicht.
Trotzdem beschreiben wir die Installationen getrennt, da vermutlich für Windows die meisten auf die ausführbare Datei und nicht auf die ZIP-Datei zurückgreifen werden. Ob man einen Installer oder das direkte Entpacken ins Zielverzeichnis vorzieht, ist sicher Geschmackssache.

Zum SeitenanfangZum Seitenanfang

Windows

Wir zeigen hier nicht jeden Schritt mit einem Screenshot, da viele Schritte selbsterklärend sind oder einfach das übliche Verhalten von Installern an den Tag legen. Lediglich interessante Schritte dokumentieren wir zusätzlich zur Beschreibung auch mit einem Screenshot.
Startet man die Datei "jakarta-tomcat-5.0.29.exe", bekommt man zunächst kurz einen Splashscreen, bevor man dann der Lizenzvereinbarung zustimmen muss. Tomcat unterliegt natürlich wie jede andere Software auch dem Urheberrecht. Mit der Lizenzvereinbarung wird geregelt, zu welchen Zwecken die Software genutzt und wie mit dem Source-Code der Software umgegangen werden kann. Sofern Sie nicht bereits mit der Apache-Lizenz vertraut sind, lesen Sie die Lizenz bitte vor dem Anklicken von "I Agree".
Danach folgt die Anpassung der Installation. Empfehlenswert ist eine Vollinstallation minus dem Haken bei "Service" (s. Screenshot). Tomcat als Service zu nutzen, ist nur sinnvoll bei Produktionssystemen (s. dazu das Kapitel JSP-Container). Bei Produktionssystem wiederum sollte der Haken unbedingt gesetzt sein (dafür braucht das Produktionssystem sicher keine Beispiele und wohl auch nicht den Source-Code).
screen_tomcat_install_windows_config.png
Nun kann man - wie bei Installationen üblich - den Installationspfad auswählen. Es empfiehlt sich, den vorgeschlagenen Pfad etwas zu kürzen. Mitunter kann es sinnvoll sein, über die Eingabeaufforderung in das Verzeichnis zu wechseln. Mit dem vordefinierten Pfad wird das schnell zur Qual.
Zur Verwaltung von Tomcat über die Web-Oberfläche gibt es zwei Nutzerrollen "admin" und "manager" (das Konzept der Nutzerrollen wird im Kapitel Deklarative Sicherheit erläutert). Diese Nutzerrollen werden im folgenden Konfigurationsschritt auf einen Nutzernamen gemappt. Dieser ist standardmäßig "admin". Das Passwort wird in der Grundkonfiguration im Übrigen im Klartext in eine xml-Datei geschrieben. Man sollte sich also Gedanken darüber machen, wer evtl. Zugang zu dem Rechner oder über einen Remote-Zugang, Freigaben etc. Zugriff auf die Datei hat und ausnahmsweise ein eher simples Passwort nehmen. In Produktiv-Systemen wird man das Mapping von Rollen zu Nutzern ohnehin anders vornehmen. Achtung: Diese Rollen und deren Verwaltung sind vollständig Container-spezifisch, und andere Container als Tomcat nutzen andere Rollen oder andere Konzepte zur Verwaltung des Containers.
In dem Panel zur Konfiguration wird zudem festgelegt, auf welchen Port Tomcat auf Anforderungen lauschen soll. Die Standardeinstellung 8080 hat inzwischen schon quasi Tradition.
screen_tomcat_install_windows_adminAccount.png
Danach muss man angeben, welche JVM genutzt werden soll. Achtung: Eine simple Java Runtime Engine (JRE) reicht nicht aus, da Tomcat in der Version 5.0 "javac" zum Compilieren der aus den JSPs generierten Servlets benötigt. Ab der Version 5.5 ändert sich dies. Tomcat wird dann mit einem Compiler fertig ausgeliefert und benötigt kein vollständiges Java-SDK mehr. Da wir die neue Version bisher noch nicht eingesetzt haben, haben wir hier noch Tomcat 5.0 benutzt. Bei Gelegenheit werden wir die Änderungen nachtragen.
Es folgt der eigentliche Installationsvorgang, der relativ zügig abgeschlossen ist. Wie immer kann abschließend ausgewählt werden, ob man Tomcat direkt starten will und das Readme lesen will.
Danach ist Tomcat bereit, um gestartet zu werden (falls er nicht direkt im letzten Schritt gestartet wurde). Dazu gibt es unter Windows zwei Arten. Man kann entweder einfach die Datei "Tomcat5.exe" im "bin"-Verzeichnis des Tomcat-Installationsverzeichnisses aufrufen oder man kann Tomcat über das dortige Skript "startup.bat" starten und über "shutdown.bat" stoppen. Im ersten Fall muss man nichts weiter beachten.
Beim Starten und Stoppen von Tomcat mit den mitgelieferten Skripten ist es wichtig, dass die Umgebungsvariable "JAVA_HOME" gesetzt ist. Ggf. kann man das unter Start-&gt;Einstellungen-&gt;Systemsteuerung-&gt;System-&gt;Umgebungsvariablen1 nachholen. Legen Sie hier durch Klick auf den Button "Neu" die Variable JAVA_HOME an, die auf das Basisverzeichnis Ihrer JDK-Installation verweist.
screen_java_home_windows.png
Starten Sie nun "Tomcat5.exe" oder "startup.bat" im "bin"-Verzeichnis Ihrer Tomcat-Installation. Es geht ein Eingabeaufforderungsfenster auf, und es erscheinen einige Logging-Ausgaben zum Startprozess von Tomcat. Der Server ist vollständig hochgefahren, wenn die Meldung "Server startup in xyz ms" erscheint.
Wenn Sie in einer Eingabeaufforderung nun "netstat -an" eingeben, sollte die Adresse TCP 0.0.0.0:8080 mit dem Status "ABHÖREN" erscheinen. Das besagt, dass Tomcat nun auf allen Netzwerk-Interfaces auf dem Port 8080 auf Client-Anfragen wartet. Auch dies ist wieder eine Einstellung, die nur auf Entwicklungsrechnern Sinn macht.
Wir prüfen abschließend den Erfolg der Installation im Browser. Wenn folgendes Bild erscheint, haben Sie Tomcat erfolgreich installiert und Sie können mit dem Schreiben von JSPs loslegen.
screen_tomcat_install_success_windows.png

Zum SeitenanfangZum Seitenanfang

Unix/Mac OS X/Linux/BSD

Die Installation unter Unix ist wahrlich simpel. Man entpackt einfach im Zielverzeichnis die gepackte Datei wie folgt:
tar -zxvf jakarta-tomcat-5.0.29.tar.gz
Es wird dabei das Verzeichnis "jakarta-tomcat-5.0.29" mit diversen Unterverzeichnissen angelegt. Da man von Zeit zu Zeit neue Versionen aufspielen muss/will, lohnt es sich u.U., einen symbolischen Link anzulegen. Bspw. mit absoluten Pfadangaben wie folgt:
ln -s /usr/local/jakarta-tomcat-5.0.29 /usr/local/tomcat
Dann braucht man nach der Installation einer neuen Version nur noch den Link umzubiegen, und alle vorhandenen Skripte laufen unverändert weiter. Diesen Link könnte man zudem noch der Umgebungsvariablen $TOMCAT_HOME zuordnen und in seine Shell-Start-Skripte einbauen.
Unter Unix werden die Rollen "admin" und "manager" standardmäßig keiner Nutzerin zugeordnet. Beim Entwickeln ist aber insbesondere die Manager-Konsole interessant. Daher legen wir noch einen Nutzernamen an. In der Datei $TOMCAT_HOME/conf/tomcat_users.xml fügen wir dazu die folgende Zeile als vorletzte Zeile ein:
<user username="admin" password="XYZ" roles="admin,manager" />
Das Passwort sollte mit Bedacht gewählt werden, steht es doch in der Datei im Klartext!
Nun kann Tomcat gestartet werden. Wir wechseln dazu in das Verzeichnis $TOMCAT_HOME/bin und starten die Datei "startup.sh". Und zum Stoppen später einfach die Datei "shutdown.sh".
Wir kontrollieren den Start mit "netstat -tpan" und sollten einen Eintrag finden, der besagt, dass unser Tomcat auf allen Interfaces (0.0.0.0) auf dem Port 8080 lauscht.
Wir kontrollieren das noch kurz im Browser. Wenn der folgende Bildschirm erscheint, war die Installation erfolgreich:
screen_tomcat_install_success_linux.png

Zum SeitenanfangZum Seitenanfang

Die Tomcat-Verzeichnisstruktur

Tomcat hat eine logisch aufgebaute Verzeichnisstruktur. Serverweit gültige Konfigurations-Dateien befinden sich im "conf"-Verzeichnis, Logging-Dateien werden im "logs"-Verzeichnis abgelegt. "bin" enthält, wie wir schon oben kennen gelernt haben, die Dateien zum Starten und Stoppen des Servers. Besonders wichtig sind aber die Verzeichnisse "work" und "webapps".
"work" enthält in seinen Unterverzeichnissen alle übersetzten JSPs. Sowohl die daraus generierten Java-Dateien als auch die übersetzten Class-Files. Es kann mitunter bei der Problemsuche nützlich sein, darauf zurückzugreifen.
"webapps" enthält - wie der Name schon sagt - alle Webanwendungen, die unter diesem Container laufen sollen. Das ist zwar etwas vereinfacht, da man auch virtuelle Server anlegen und diesen eigene Verzeichnisse für die Webanwendungen zuordnen kann, aber für Entwicklungsrechner ist das wohl eher unerheblich. Eine Webanwendung sticht im Verzeichnis "webapps" schon namentlich hervor. "ROOT" ist die Anwendung, die zum Tragen kommt, wenn keine der anderen passt.
Schauen wir uns dazu genauer den Verzeichnis-Baum an:
screen_tomcat_directory_tree.png
Tomcat kommt mit diversen Beispielen für kleinere JSPs und Servlets. Diese sind jeweils unter den Verzeichnissen "jsp-examples" bzw. "servlet-examples" zu finden. Ruft man nun die URL "http://localhost:8080/jsp-examples" im Browser auf, so wird nicht etwa ein Unterverzeichnis der Webanwendung "ROOT" benutzt, sondern eine eigenständige Anwendung. Auf diese Weise können die Bibliotheken und die Konfigurationen verschiedener Anwendungen (im Unterschied zur Konfiguration des Containers) sauber getrennt werden. Web-Anwendungen werden zumeist in der Form von Archiv-Dateien, sogenannten "war"-Dateien (für Web-Archiv), deployt2. Beim Tomcat reicht es dazu aus, die entsprechende "war"-Datei in das Verzeichnis "webapps" zu verschieben. Je nach Konfiguration wird die Anwendung direkt erkannt und automatisch eingebunden (sogenanntes Hot-Deployment) oder erst nach einem Neustart des Servers. Außerdem wird je nach Konfiguration die "war"-Datei in ein entsprechend benanntes Verzeichnis entpackt oder sie bleibt unausgepackt. Die Webanwendung ist bei "war"-Dateien anschließend unter dem Namen der Datei ohne deren Endung erreichbar. Also für "myFirstWebapp.war" wäre dies "http://127.0.0.1:8080/myFirstWebApp".
Aufgrund ihrer Bedeutung sind die Webanwendungen "manager" und "admin" nicht im "webapps"-Verzeichnis, sondern im Verzeichnis "server/webapps" zu finden.

Zum SeitenanfangZum Seitenanfang

Die "manager"- und die "admin"-Anwendungen

Tomcat liefert von Haus aus einige Web-Anwendungen mit (s. Screenshot). Die Anwendungen "jsp-examples" und "servlets-examples" dienen Einsteigerinnen als mögliche Startpunkte und Beispiele für erste Schritte mit den jeweiligen Technologien. Wichtig ist natürlich auch die Anwendung "tomcat-docs", die die vollständige Doku enthält. Vor allem aber zwei Anwendungen verdienen Beachtung: Die "manager"- und die "admin"-Anwendungen.
Die "manager"-Anwendung ermöglicht es, gezielt einzelne Anwendungen zu löschen, neu zu starten, zu stoppen oder auch neue WAR-Dateien aufzuspielen (s. Screenshot) . Zum Hochladen einer neuen Anwendung wird einfach die war-Datei einer Anwendung mittels "Browse" aus dem Dateisystem ausgewählt und dann durch Absenden des Formulars installiert. Dies ist sicherlich sehr komfortabel. Auch schön ist, dass man hier gezielt einzelne Anwendungen neu starten kann. Mit den Start- und Stopp-Skripts "startup.sh" und "shutdown.sh" kann man stets nur den gesamten Container starten und stoppen. Letzteres macht m.E. die "manager"-Anwendung für Entwicklerinnen sehr nützlich. Das gezielte Neustarten einer Anwendung ist logischerweise deutlich schneller als ein kompletter Neustart des Containers!
screen_manager_app.png
Allerdings geht diese Einfachheit leider auch mit einer großen Gefahr einher. Die obige Auflistung der Möglichkeiten der "manager"-Anwendung macht deutlich, dass der Zugriff auf die "manager"-Anwendung gut geschützt werden muss. Ansonsten kann man von "remote" aus den Container komplett lahm legen oder einfach neue Apps aufspielen. Wenn die "manager"-Anwendung überhaupt (außerhalb des eigenen Netzwerkes) sichtbar sein soll, sollte unbedingt sicher gestellt sein, dass die Anwendung nur über eine gesicherte HTTPS-Verbindung genutzt werden kann und dass bei Produktiv-Umgebungen gescheite Passwörter verwendet werden.
Die "admin"-Anwendung erleichtert einem ebenfalls das Leben. So sind einige Konfigurationen hier bequemer (aber nicht unbedingt schneller) vorzunehmen als über die Konfigurationsdateien. Andererseits bietet die "admin"-Anwendung in Tomcat 5.0 noch zu wenig Möglichkeiten, als dass sich deren Einsatz wirklich lohnen würde. Wichtige Einstellungen fehlen, und man kommt ohnehin nicht um die Konfigurationsdateien herum. Vermutlich ist die Anwendung in der neuesten Tomcat-Version (5.5) schon besser einsetzbar. Wir werden die Änderungen hier bei Gelegenheit nachtragen.

Zum SeitenanfangZum Seitenanfang

Die wichtigsten Konfigurations-Dateien für den Einstieg

Abschließend sollen noch kurz ein paar wichtige Dateien erwähnt werden. Nicht eingegangen wird auf die Dateien und die Verzeichnisstruktur für Web-Applikationen, wie sie von den Servlet- und JSP-Spezifikationen vorgeschrieben sind. Diese werden im Kapitel Verzeichnisstruktur von Java-Webanwendungen beschrieben.

/bin/startup.sh /bin/shutdown.sh /bin/catalina.sh

Die Dateien "/bin/startup.sh"3 und "/bin/shutdown.sh" sind lediglich kurze Skripte, die letztlich "/bin/catalina.sh" mit dem benötigten Startparameter aufrufen.

/logs/catalina.out

Die wichtigste Logging-Datei. Hier werden von Tomcat alle Log-Meldungen des Containers selber als auch die System.out.-, System.err- und Logging-Meldungen der Anwendungen hineingeschrieben. Auch dann, wenn der Container nicht startet, lohnt sich ein Blick in diese Datei. Konfigurations-Dateien liegen z.B. durchweg als xml-Dateien vor. Sind diese syntaktisch nicht korrekt, findet man hier die Angabe, an welcher Stelle das Parsen der XML-Datei gescheitert ist.

/conf/server.xml

Die zentrale Konfigurations-Datei. Hier wird bestimmt, auf welchen Ports der Server lauschen soll. Auch virtuelle Hosts kann man hier einrichten. Diese Datei wird gründlich im Kapitel JSP-Container vorgestellt, das ausführlich auf Produktionsumgebungen eingeht.

/conf/web.xml

Jede Webanwendung hat eine eigene Datei "/WEB-INF/web.xml", wie im Kapitel Verzeichnisstruktur von Java-Webanwendungen beschrieben. Die "web.xml" Datei im "conf"-Verzeichnis hingegen definiert das Default-Verhalten aller Webanwendungen! So wird hier auch festgelegt, wie sich Tomcat beim Transformieren von JSPs in Servlet-Code verhalten soll oder wie lang der Standard-Session-Timeout ist, solange in den einzelnen web.xml-Dateien dieser Wert nicht überschrieben wird. Auch diese Datei wird im Kapitel JSP-Container genauer beschrieben.

/conf/tomcat-users.xml

Tomcat bietet mehrere Möglichkeiten zur Authentifizierung von Nutzerinnen (sogenannte Realms). Die standardmäßig voreingestellte Methode ist das Eintragen von Nutzerinnen in die Datei "/conf/tomcat-users.xml". Wie schon oben beschrieben, nutzt Tomcat diese Datei standardmäßig zur Authentifizierung der "admin"- und der "manager"-Rolle. In Produktiv-Anwendungen wird man wohl nie mit dieser Datei arbeiten, sondern auf datenbankgestützte oder JNDI(LDAP)-gestützte Methoden zurückgreifen. Mehr dazu im Kapitel Deklarative Sicherheit.

Zum SeitenanfangZum Seitenanfang

Anmerkungen:

1) Dies zumindest ist die Folge der Schritte auf einem Windows 2000-System (zurück)

2) Das "Deployment" einer Anwendung umfasst die Installation und Konfiguration einer Anwendung, hier also einer Webanwendung in den Container. (zurück)

3) Wir verwenden hier durchgängig die UNIX-Schreibweise. Bei Windows ist der Verzeichnistrenner natürlich der Backslash "\", und anstelle der Dateiextension ".sh" wird unter Windows die Dateiextension ".bat" verwandt. (zurück)


www.jsptutorial.org
© 2005, 2006, 2007