Um Ihren Kontextpfad auf "/" festzulegen, sollten Sie eine Context-Bereitstellung verwenden. Hinweis: Sie MÜSSEN einen Kontextpfad-String für die Zuordnungsgründe des Pfadspezifikators angeben. Ein leerer Kontextpfad-String "" ist nur als Zuordnungsergebnis von Anfragen an den Kontext-Root gültig. Siehe Abschnitt 12.2 der Servlet-Spezifikation)
In Jetty 7.x wird die Kontextpfadzuweisung von den dem DeploymentManager zugewiesenen App-Anbietern gehandhabt.
Standardmäßig sind sowohl der WebAppProvider als auch der ContextProvider auf der Jetty-Distribution aktiviert. Dies ist später wichtig zu wissen, da es Ihre Entscheidungen beeinflussen wird, wo die mywebapp.war-Datei platziert werden soll.
Sehen Sie sich die Datei ${jetty.home}/start.ini an, und Sie werden feststellen, dass sie sowohl Verweise auf etc/jetty-webapps.xml als auch auf etc/jetty-contexts.xml enthält.
Die Rolle des WebAppProviders besteht darin, das ${jetty.home}/webapps/-Verzeichnis auf deploybare Anwendungen (z. B. *.war) zu überwachen und sie in einen Kontext mit dem gleichen Namen wie die Datei zu deployen. Mit anderen Worten wird ${jetty.home}/webapps/MyApp-2.4.war in den Kontext "/MyApp-2.4" deployt. Es gibt auch das spezielle reservierte Wort "root.war", das in den Kontext "/" deployt wird. Obwohl dies der einfachste Bereitstellungsmechanismus ist, geht die Kontrolle über die Bereitstellungsdetails verloren.
Die Rolle des ContextProviders besteht darin, das ${jetty.home}/contexts/-Verzeichnis auf jetty-xml-formatierte deploybare Kontexte zu überwachen. Dieser Bereitstellungsmechanismus gibt Ihnen die maximale Kontrolle über die Bereitstellung, die XML-Datei kann alles kontrollieren, was letztendlich in einer org.eclipse.jetty.server.handler.ContextHandler Basisklasse aufgelöst wird, zu der auch WebAppContext (wars / servlets / etc.) gehören. Die häufigste Verwendung besteht darin, eine auf WebAppContext basierende XML-Datei anzugeben und Dinge wie die Dateien und Verzeichnisse festzulegen, die die Webanwendung ausmachen, welches temporäre Verzeichnis verwendet werden soll und sogar welchen Kontextpfad verwendet werden soll.
Was Sie tun müssen, ist:
- Stellen Sie sicher, dass Ihre auf ContextProvider basierenden Bereitstellungen in der start.ini aktiviert sind (vergewissern Sie sich, dass
etc/jetty-context.xml vorhanden ist)
- Erstellen Sie eine
${jetty.home}/contexts/mywebapp.xml, die die Option / deklariert.
- Wenn sich die Datei
etc/jetty-webapps.xml in Ihrer start.ini befindet, platzieren Sie Ihre mywebapp.war NICHT in ${jetty.home}/webapps, da der WebAppProvider dieselbe Webanwendung ebenfalls deployt und Ihre Bereitstellung verwirrt.
Schließlich können Sie sehen, wie dies in der Jetty-Distribution selbst gemacht wird, öffnen Sie einfach die ${jetty.home}/contexts/test.xml und schauen Sie sich um. Sie werden feststellen, dass sie die ${jetty.home}/webapps/test.war über die Verwendung der ${jetty.home}/contexts/test.xml in den Kontextpfad "/" laden.
Weitere Anmerkung, schauen Sie sich die Protokolle an.
2012-01-13 13:56:28.779:INFO:oejsh.ContextHandler:started o.e.j.w.WebAppContext{/,file:/tmp/jetty-0.0.0.0-8080-test.war-_-any-/webapp/},/home/joakim/code/jetty/distros/jetty-distribution-7.6.0.RC3/webapps/test.war
Das sagt mir, dass der WebAppContext
- Auf
{/, (dem Root-Kontextpfad) gestartet wurde
- Das temp/work-Verzeichnis
file:/tmp/jetty-0.0.0.0-8080-test.war-_-any-/webapp/ verwendet
- Die in
/home/joakim/code/jetty/distros/jetty-distribution-7.6.0.RC3/webapps/test.war spezifizierte Webanwendung verwendet wird.
Update: Klarstellung zur Aussage über den leeren Kontextpfad.
