nicht angemeldet
Hi Slyh,
ich habe dazu einen kleinen Test durchgeführt.
Environment:
OS: WinXP Professional (kein SP)
Tomcat: jakarta-tomcat-4.0.6
Java-Runtime: jdk_1.4.2_02
Ich habe das Tomcat.zip entpackt und ein zusätzliches Webapp-Verzeichnis ("MyTest") samt "WEB-INF"-Unterverzeichnis angelegt. Als <web.xml> verwendete ich (durch Kopie) diejenige aus der "Root"-WebApplikation. Diese hat folgenden Inhalt:
<?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>
Es existiert also keinerlei WebApplikations-spezifische Konfiguration. Die "jungfräuliche" <server.xml> hat ebenso auch "(noch) keine Ahnung" über einen Context dieser WebApplikation.
Folgende Dateien kopierte ich aus der "Examples"-WebApp nach TOMCAT_HOME/webapps/MyTest/WEB-INF/classes:
HelloWorldExample.class
LocalStrings.properties
LocalStrings_en.properties
LocalStrings_es.properties
LocalStrings_fr.properties
Nach Start von Tomcat und Request der URL "http://localhost:8080/MyTest/servlet/HelloWorldExample" zeigte mir der Browser (Opera 7.23) ein HTML-Dokument mit folgendem Inhalt:
"Hello World!"
Daraus folgt (zumindest für die getestete Tomcat-Version):
Es gibt kein Standardverzeichnis. Das Verzeichnis läßt sich
beliebig in der server.xml festlegen. Genaugenommen _muß_ es festgelegt
werden, damit es funktioniert.
Es _gibt_ durchaus ein Standard-Verzeichnis. Tomcat "sucht" genau dann (bei Verwendung obigen URL-Musters) in diesem nach Servlet-Klassen, wenn eine WebApplikation _nicht_ explizit als "Context" in der <server.xml> mitgeteilt wurde. Dieses Verhalten ist bei Betrachtung des "unpackWARs"-Features (Eigenschaft eines Tomcat-Hosts) auch sinnvoll (und so spezifiziert). D.h., ein Standardverzeichnis muss eben _nicht_ festgelegt werden (sonst wäre es doch auch kein Standardverzeichnis, oder?). Allerdings _kann_ ein Context definiert werden. Im dort definierten "path" wird dann zuerst nach den resourcen "gesucht".
Ich definiere (richtiger: "definierte" - die Konfiguration von Tomcat während der Entwicklung durch mich ist auch schon wieder einige Monate her..) einen Webapp-Context nur dann, wenn die Resourcen _nicht_ in den Standardverzeichnissen unterhalb von TOMCAT_HOME liegen (z.B. weil das Projekt-Setup dies - sinnvollerweise oder auch nicht - erfordert).
Ja. Allerding ist seit Tomcat 4 diese "/servlet"-Geschichte aus
Sicherheitsgründen in der web.xml auskommentiert. Konkret sind das
folgende 4 Zeilen:<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
s.o.
Wenn man diese Zeilen unkommentiert (gibt's dafür ein deutsches
Wort?),
ich schreibe immer "uncommented" ;-)) "Auskommentiert" wäre wohl korrekter.
so wird der Teil nach "servlet/" als vollqualifizierter
Klassenname interpretiert und die entsprechende Klasse ausgeführt,
sofern diese im Classpath liegt.
(Vollqualifiziert heißt, daß der Package-Name mit angegeben werden muß.)
Stimmt - und "servlet/" wird standardmäßig nach <TOMCAT_HOME/webapps/MeineWebApplikation/WEB-INF/classes> aufglöst.
Das ist aber alles viel zu umfangreich und kompliziert, um das hier
abzuhandlen -- zumal zu wenige Informationen gegeben werden.
Die Konsultation der Handbücher und das genaue Studieren der
Kommentare in der web.xml und server.xml wären da wohl sinnvoller.
Diese Kommentare empfand ich als Anfänger immer als Zumutung...wie eigentlich die gesamten offiziellen Tomcat-Docs.
Daher: http://csajsp-chapters.corewebprogramming.com/Core-Servlets-and-JSP.pdf
Bei Google findet man üblicherweise auch sehr viele Hinweise.
Ansonsten kann ich noch das Tomcat-Sysdeo-Plugin für Eclipse empfehlen.
Die meisten Dinge nimmt einem das ab. (Insbesondere das Starten
des Server und das Konfigurieren der Applikations-Pfade. Nicht aber
das Erstellen der applikationsspezifischen web.xml.)
Benutze ich ausschließlich. Klar, führt natürlich dazu, die "Energie des Verstehens" nicht mehr zu fühlen..
Das ist vor allem dann fatal, wenn es auf dem Zielsystem kein solches Plugin samt (Eclipse-)Runtime gibt und in der Shell so eignenartige Meldungen erscheinen ;-)
Viele Grüße,
Martin