Servlet - Problem mit Pfadangaben

[Manuel]

Hallo,

ich hab auf dem Server unter /export/home/meinName/ folgende Verzeichnisse und Dateien:

public_html
-index.htm

servlets
-ServletForm.class

Im File index.htm habe ich die Zeile:
<form action="servlets/ServletForm" method="post">

Wenn ich das Formular auf http://www.meinHost.com/~meinName/index.htm absende, dann erscheint jedoch immer der Fehler:

The requested URL /~meinName/servlets/ServletForm was not found on this server.

Was mache ich da falsch?

Gruss Manuel

[Slyh]

Hallo,

ein bißchen wenig Infos, die du da gibst. Anhand der Verzeichnisstruktur
kann man nicht sehr viel beurteilen. Schon alleine weil du nicht sagst
welchen Server du verwendest und wie deine Applikation konfiguriert ist.

Im File index.htm habe ich die Zeile:
<form action="servlets/ServletForm" method="post">

Ich spekuliere einfach mal, daß vor "servlets" ein Slash (/) fehlt.

Gruß
Slyh

[Manuel]

Hallo Slyh:

Der Server: Apache/1.3.27 Server

Wenn ich den Slash hinzufüge:
"The requested URL /servlets/ServletForm was not found on this server."

Gruss Manuel

[Slyh]

Hallo,

Der Server: Apache/1.3.27 Server

Kein Tomcat, JBoss, Websphere oder ähnliches laufen?
Wie willst du dann Servlets ausführen?

Gruß
Slyh

[Manuel]

Hallo,

Kein Tomcat, JBoss, Websphere oder ähnliches laufen?
Wie willst du dann Servlets ausführen?

Es läuft Tomcat, ist aber übrigens nicht mein eigener Server.

Gruss Manuel

[Martin Jung]

Hi,

Ich spekuliere einfach mal, daß vor "servlets" ein Slash (/) fehlt.

Soweit ich weiß ist das Standardverzeichnis für Servlets unter Tomcat[*]
TOMCAT_HOME/webapps/dasProject/WEB-INF/classes  ?

Und in der URL muss beim Zugriff (sofern kein explizites Mapping in der <web.xml> angegeben) meines Wissens der _Singular_ verwendet werden. Also: "servlet/servletForm"

Hinweis zu weiterer Fehlersuche: Mit eine absoluten URL funktioniert es genauso wenig?

Viele Grüße,
Martin Jung

[*] zumnindest für Versionen < 5

[Slyh]

Hallo,

Ich spekuliere einfach mal, daß vor "servlets" ein Slash (/) fehlt.
Soweit ich weiß ist das Standardverzeichnis für Servlets unter Tomcat[*]
TOMCAT_HOME/webapps/dasProject/WEB-INF/classes  ?

Es gibt kein Standardverzeichnis. Das Verzeichnis läßt sich
beliebig in der server.xml festlegen. Genaugenommen _muß_ es festgelegt
werden, damit es funktioniert.
Du hast recht, daß die Web-Applikationen ins webapps gelegt werden
sollten, und daß darin ein Verzeichnis WEB-INF existiert usw.

Und in der URL muss beim Zugriff (sofern kein explizites Mapping in der <web.xml> angegeben) meines Wissens der _Singular_ verwendet werden. Also: "servlet/servletForm"

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>

Wenn man diese Zeilen unkommentiert (gibt's dafür ein deutsches
Wort?), 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ß.)

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.

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.)

Gruß
Slyh

[Martin Jung]

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

[Martin Jung]

Moin Slyh,

was ich vergaß zu fragen:

Ja. Allerding ist seit Tomcat 4 diese "/servlet"-Geschichte aus
Sicherheitsgründen in der web.xml auskommentiert.

Kennst Du die Hintergründe genauer?

Nachtrag zu meiner ersten Antwort:
Das "Standardverzeichnis" für Servlets in Tomcat ist der Default-Classpath einer WebApplikation. Ohne ein explizites Servlet-Mapping in der <web.xml> müssen Servlets mit "servlet/VollQualifizierterKlassenName" in der URL angesprochen werden.

Viele Grüße,
Martin

[Slyh]

Hallo,

bezugnehmend auf deine vorherige Antwort auf mein Posting:
Du hast zu viel Zeit! :-)
Ich werd das aber mal nachvollziehen, was du schreibst, sobald ich ein
wenig Zeit habe. Insbesondere auch um das Verhalten von Tomcat 5 zu
ermitteln.
(Ich hoffe, das der Thread noch nicht vorher ins Archiv wandert.)

Ich kann nur sagen, daß ich mit Tomcat 4 (vielleicht war's auch 5)
verschiedentlich Probleme hatte, wenn ich nicht sehr genau konfiguriert
hatte, was wo liegt usw.

Ja. Allerding ist seit Tomcat 4 diese "/servlet"-Geschichte aus
Sicherheitsgründen in der web.xml auskommentiert.
Kennst Du die Hintergründe genauer?

Nicht wirklich. Es gab wohl mal eine Sicherheitslücke dazu. Siehe
http://jakarta.apache.org/tomcat/faq/misc.html#invoker und
auch die nachfolgende Frage. Es ist einfach schlechter Stil und
birgt gewisse Risiken, den Invoker per Wildcard zu verwenden.

Lokal sehe ich zu Testzwecken aber kein Problem.

Nachtrag zu meiner ersten Antwort:
Das "Standardverzeichnis" für Servlets in Tomcat ist der Default-Classpath einer WebApplikation.

Meinst du das "Default-Package"?

Ohne ein explizites Servlet-Mapping in der <web.xml> müssen Servlets mit "servlet/VollQualifizierterKlassenName" in der URL angesprochen werden.

Ja. Das hätte ich noch explizit erwähnen sollen. Wenn man sowas wie
"servlet/MeineKlasse" über den Invoker starten lassen möchte, so muß
die Klasse "MeineKlasse" im Default-Package (also keinem Package)
liegen.
Liegt die Klasse in einem Package, sähe der Aufruf ungefähr so aus:
"servlet/de.meinpackage.MeineKlasse".

Oder meintest du was anderes?

Gruß
Slyh

[Martin Jung]

Hi,

bezugnehmend auf deine vorherige Antwort auf mein Posting:
Du hast zu viel Zeit! :-)

Gestern Abend und heute Morgen ja - ansonsten kaum ;-(

Ich kann nur sagen, daß ich mit Tomcat 4 (vielleicht war's auch 5)
verschiedentlich Probleme hatte, wenn ich nicht sehr genau konfiguriert
hatte, was wo liegt usw.

Tomcat Konfigurationsproblem im Allgemeinen sind mir auch bekannt ;-)

Nicht wirklich. Es gab wohl mal eine Sicherheitslücke dazu. Siehe
http://jakarta.apache.org/tomcat/faq/misc.html#invoker und
auch die nachfolgende Frage. Es ist einfach schlechter Stil und
birgt gewisse Risiken, den Invoker per Wildcard zu verwenden.

Dem stimme ich uneingeschränkt zu.

Meinst du das "Default-Package"?

Nein, sondern: TOMCAT_HOME/webapps/DieWepApplikation/WEB-INF/classes (siehe meine Antwort von gestern Abend)

Oder meintest du was anderes?

Nein - genau das.
Abgesehen davon würde ich für den Clienten sowieso nur ein Servlet zugänglich machen, welches dann als Command-Dispatcher (und somit als Filter)funktioniert.

Viele Grüße,
Martin

[Martin Jung]

Hi Slyh,

weiterer Nachtrag:
natürlich habe gerade ich in der allgemeinen <web.xml> (/conf) meiner Beispel Tomcat-Installation besagtes "böses" Mapping auf das Invoker-Servlet gefunden. Damit ist mein beschriebenes Verhalten natürlich erklärt, gar nicht mehr "mystisch" und vor allem "abschaltbar".

Viele Grüße,
Martin Jung

[Manuel]

Hallo Slyh,

hab noch rausgefunden, dass wenn ich in den das servlets Verzeichnis wechsle, ich eigentlich hier bin:

"Remote Directory is /var/apache/servlets/meinName"

Gruss Manuel