Java Reference
In-Depth Information
Zum Abrufen einer Datei muss man als URL den Web-Server, dessen Portnummer (falls es
nicht die Portnummer 80 ist), den Namen der Komponente (identisch mit dem Namen des
Verzeichnisses in webapps) sowie den Pfad zu dieser Datei innerhalb des Anwendungsver-
zeichnisses angeben. Wenn wir also davon ausgehen, dass der Tomcat-Server auf einem
Rechner mit dem Namen www.abc.de gestartet wurde und standardmäßig auf dem Port
8080 lauscht, dann kann die HTML-Datei a.html aus Bild 12.1 unter folgender URL abgeru-
fen werden:
http://www.abc.de:8080/application1/a.html
Entsprechend lautet die URL für die Datei d.html:
http://www.abc.de:8080/application1/dir/d.html
Wie in Bild 12.1 zu sehen ist, gibt es auch ein Verzeichnis WEB-INF mit einer Datei web.
xml. Man könnte nun analog zu den obigen HTML-Dateien eine URL für web.xml bilden:
http://www.abc.de:8080/application1/WEB-INF/web.xml
Der Abruf der Datei web.xml mit dieser URL würde aber scheitern, da das Verzeichnis WEB-
INF eine Sonderstellung einnimmt. Dieses Verzeichnis und alle seine Inhalte sind von außen
über das HTTP-Protokoll nicht sichtbar. Das Verzeichnis WEB-INF dient primär zur Speiche-
rung der Konfi gurationsdatei web.xml für diese Web-Komponente sowie der Class-Dateien
der Servlets und der von den Servlets benutzten Klassen. Die Class-Dateien müssen in dem
Unterverzeichnis classes von WEB-INF in Form einzelner Klassen (mit Package-Pfadnamen)
und/oder in dem Unterverzeichnis lib in Form von Jar-Dateien abgelegt werden. Mit anderen
Worten: Zum Klassenpfad einer Web-Komponente gehört also das Verzeichnis WEB-INF/
classes sowie alle Jar-Dateien in WEB-INF/lib. In Bild 12.1 existiert lediglich das Unterver-
zeichnis classes. Da der erste Teil der in diesem Buch verwendeten Package-Namen immer
javacomp ist, muss also classes ein Verzeichnis namens javacomp besitzen. Die weitere
Struktur von javacomp wird der Einfachheit halber in Bild 12.1 nicht gezeigt.
Eine Web-Entwicklerin kann nun direkt auf der vorgestellten Verzeichnisstruktur für die
einzelnen Anwendungen bzw. Komponenten unter webapps arbeiten. Es gibt aber auch die
beiden folgenden Alternativen:
!
Es kann eine War-Datei (das ist eine Jar- oder Zip-Datei mit der Endung .war für „Web
Archive“) in webapps abgelegt werden. Der Web-Server entpackt diese Datei dann unter
webapps (das ist sehr ähnlich wie beim prototypischen Komponentensystem aus Kapitel
6). Damit die Struktur der Web-Anwendung korrekt ist, muss die War-Datei bereits die
richtige Struktur — wie oben beschrieben — haben. Wird die War-Datei wieder gelöscht, so
wird die Web-Anwendung samt der entpackten Verzeichnisstruktur ebenfalls gelöscht
(auch dies erinnert an das prototypische Komponentensystem).
!
Eine weitere Alternative besteht darin, dass das Verzeichnis für eine Web-Anwendung
außerhalb des Verzeichnisses webapps angelegt wird, und dass der Tomcat-Server einen
Hinweis erhält, wo es ein Verzeichnis für eine weitere Web-Komponente außerhalb von
webapps gibt. Dies ist besonders nützlich, wenn man mit einer Entwicklungsumgebung
wie Eclipse seine Web-Anwendung erstellt und diese im Workspace seiner Entwicklungs-
umgebung abspeichern möchte. Diese Variante ist die Alternative meiner Wahl. Ich ver-
wende ausschließlich diese Möglichkeit für die Web-Anwendungen in diesem Buch.
