☰

So stellen Sie eine Tomcat-Anwendung mit Manager-URL-API bereit, wenn Sie benutzerdefiniertes Kontext-XML verwenden

tag-icon • tag-icon tomcat
So stellen Sie eine Tomcat-Anwendung mit Manager-URL-API bereit, wenn Sie benutzerdefiniertes Kontext-XML verwenden

Mein Anwendungskontext ist als XML-Datei definiert, die sich im Verzeichnis befindet my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml.

<Context docBase='/my/path/to/myApp/myAppWarFile.war'>
   <Environment name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/>
</Context>

/my/path/to/myAppenthält die WAR-Datei myAppWarFile.war und eine Reihe externalisierter Eigenschaften, die von Spring gelesen werden.

Tomcat ist mit deaktiviertem AutoDeploy konfiguriert. Wenn ich Tomcat starte, wird my/path/to/Tomcat/conf/webapps/my-app/die WAR-Datei wie erwartet erstellt und an diesem Speicherort entpackt. Die Anwendung kann natürlich wie erwartet ausgeführt werden.

Wenn ich eine neue Version bereitstellen möchte, ohne Tomcat neu zu starten, führe ich den Befehl „Undeploy“ wie folgt aus:

curl http://localhost:8080/manager/text/undeploy?path=/my-app --user my-username:my-password

... und das funktioniert. Aber wenn ich Tomcat mit der folgenden Curl-Anweisung anweise, zu deployen, erhalte ich eine Fehlermeldung.

curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml --user my-username:my-password
# Tomcat response
FAIL - Invalid context path null was specified

Das Hinzufügen des Pfads hilft nicht viel, ich erhalte weiterhin eine Fehlermeldung.

curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\&path=/my-app --user my-username:my-password

# Tomcat response
FAIL - Failed to deploy application at context path /my-app

Das Schlimmste ist, dass das Nachverfolgen von catalina.out keinerlei Erkenntnisse liefert. Und obendrein löscht Tomcat die XML-Datei mit dem Anwendungskontext my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml!

Natürlich habe ich die Tomcat-Dokumentation überprüft (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file) und ich habe den ganzen Tag gegoogelt, um das herauszufinden, aber ich habe nichts gefunden, was mir bei dieser speziellen Konfiguration helfen könnte.

Es fühlt sich an, als ob die Wahl wäre:

  1. Tomcat mit aktiviertem AutoDeploy (für die Produktion nicht empfohlen). In diesem Fall reicht es aus, das neue WAR abzulegen und /my/path/to/myApp/Tomcat führt ein Hot Deploy der App aus.
  2. Tomcat mit deaktiviertem AutoDeploy, aber für die erneute Bereitstellung ist ein Neustart von Tomcat erforderlich, da die Bereitstellungs-API anscheinend nicht wie angegeben funktioniert.

Hat das irgendjemand mit dieser Konfiguration zum Laufen gebracht?

BEARBEITEN:

Ich habe die Protokollierung unter Catalina aktiviert. Wenn ich den ersten Bereitstellungsbefehl ohne Pfad ausführe, erhalte ich diese Protokolleinträge:

FINE: Start processing with input [config=file:/my/apth/to/tomcat/conf/Catalina/localhost/my-app.xml]
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [OPEN]
Oct 13, 2015 10:04:53 AM org.apache.coyote.http11.AbstractHttp11Processor process
FINE: Error parsing HTTP request header
java.io.EOFException: Unexpected EOF read on the socket
    at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:744)

Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [CLOSED]
Oct 13, 2015 10:04:53 AM org.apache.tomcat.util.threads.LimitLatch countDown
FINE: Counting down[http-bio-8080-exec-16] latch=1

Antwort1

Das Problem tritt häufig auf. Bei binären portablen War-Dateien befindet sich die Kontextkonfiguration (Umgebung) im richtigen Kontext – nicht in der War-Datei. Bei einer erneuten Bereitstellung, z. B. beim Anwenden eines Software-Patches, sollte der Container (Tomcat) erneut bereitgestellt werden, ohne den Kontext zu löschen.

Dieses Problem wird behandelt beiErneuter Einsatz aus dem Krieg ohne Kontextlöschung. Offenbar geht man davon aus, dass dies mit der Textschnittstelle bereits möglich ist, sodass ein Fall, in dem dies nicht möglich ist, als Fehler betrachtet werden könnte.

Die empfohlene Lösung besteht darin, dieses Tomcat-Problem zu beobachten, bis es behoben ist, da dieses Serverfehlerproblem ein Duplikat davon wird.

verwandte Informationen