Warum ersetzt Tomcat die Datei context.xml bei einer Neuverteilung?

Question

In der Dokumentation steht, dass Sie hier eine Kontextdatei haben:

$CATALINA_HOME/conf/Catalina/localhost/myapp.xml

sie wird hier NICHT durch eine Kontextdatei ersetzt:

mywebapp.war/META-INF/context.xml

Hier steht es geschrieben: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

Nur wenn keine Kontextdatei für die Anwendung im Verzeichnis $CATALINA_BASE/conf/[Maschinenname]/[Hostname]/ vorhanden ist, in einer eigenen Datei unter /META-INF/context.xml innerhalb der Anwendungsdateien.

Aber jedes Mal, wenn ich das War neu bereitstellen, ersetzt es diese myapp.xml mit der /META-INF/context.xml!

Warum ist das so und wie kann ich es vermeiden?

Vielen Dank

Answer 1

Der Teil "Undeploy" von "Redeploy" löscht die Anwendung und die zugehörige context.xml.

Wenn Sie das Maven-Tomcat-Plugin verwenden, können Sie das Löschen der context.xml vermeiden, wenn Sie Ihre Anwendung mit einem Befehl wie diesem bereitstellen:

mvn tomcat:deploy-only -Dmaven.tomcat.update=true

Mehr Informationen hier: https://tomcat.apache.org/maven-plugin-2.0-beta-1/tomcat7-maven-plugin/deploy-only-mojo.html

Sie können auch deploy-only mit Parametermodus verwenden, um die context.xml zu verteilen.

Answer 2

Die kurze Antwort:

Machen Sie einfach die TOMCATHOME/conf/Catalina/localhost dir schreibgeschützt, und lesen Sie weiter für weitere Details:

• Para schneller Einsatzmodus (dynamisches Eclipse-Webprojekt, direkte Tomcat Verbindung usw.) auf einem lokalen/nicht gemeinsam genutzten Tomcat-Server können Sie einfach Ihre JDBC-Datenquelle (oder jede andere 'Web-Ressource') unter Verwendung der META-INF/context.xml Datei innerhalb der WAR-Datei. Einfach und schnell in Ihrer lokalen Umgebung, aber nicht geeignet für Staging, QA oder Produktion.

• Para Build-Deployment-Modus (normalerweise für Staging, QA oder Prod), JDBC Datenquellen und andere "Web-Ressourcen" werden von der QA/Produktionsteam festgelegt, nicht mehr vom Entwicklungsteam. Daher sind sie müssen sie im Tomcat-Server angegeben werden, nicht in der WAR-Datei mehr. In diesem Fall geben Sie sie in der Datei TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml (Veränderung Catalina durch den Motor, und localhost durch den Gastgeber, und KONTEXT durch Ihren Kontext entsprechend). Wie auch immer, Tomcat löscht diese Datei bei jedem Einsatz. Um dies zu verhindern Löschen zu verhindern, machen Sie dieses Verzeichnis einfach schreibgeschützt; unter Linux können Sie eingeben:

     chmod a-w TOMCATHOME/conf/Catalina/localhost

  Voilà! Bitte sehr.

Die lange Antwort

• Aus historischen Gründen erlaubt Tomcat die Definition von Webressourcen (JDBC-Datenquellen und andere) in vier an vier verschiedenen Stellen zu definieren (vier verschiedene Dateien zu lesen), und zwar in einer ganz bestimmten Rangfolge, wenn Sie dieselbe Ressource mehrfach definieren. Die in der Antwort genannten Dateien sind heutzutage für jeden Zweck am besten geeignet, obwohl Sie auch die anderen verwenden (nein... das wollen Sie wahrscheinlich nicht). Ich werde nicht die anderen hier nicht diskutieren, es sei denn, jemand fragt danach.

Answer 3

Unter Tomcat7 wird die Datei auch bei autoDeploy=false beim Rückgängigmachen der Bereitstellung gelöscht. Dies ist dokumentiert und kein Fehler (obwohl es gute automatisierte Bereitstellungen mit serverseitiger fester Konfiguration verhindert).

Ich habe eine Lösung gefunden, die das Problem für mich behebt:

• eine META-INF/context.xml-Datei in Ihrer Webanwendung erstellen, die Folgendes enthält
• Erstellen Sie auf dem Server einen zweiten Kontext "/config-context" in der Datei server.xml und legen Sie dort alle Ihre serverseitigen Konfigurationsparameter ab.
• auf der Anwendung verwenden Sie context.getContext("/config-context").getInitParameter(...), um dort auf die Konfiguration zuzugreifen.

Dies ermöglicht eine Konfiguration pro Host, die unabhängig vom eingesetzten War ist.

Es sollte auch möglich sein, Konfigurationen pro Kontext hinzuzufügen, indem Sie Kontexte wie "/config-context-MYPATH" hinzufügen. In Ihrer Anwendung können Sie den Kontextpfad der Anwendung verwenden, um den Kontextpfad der Konfigurationsanwendung zu berechnen.

Answer 4

Laut der Dokumentation ( http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files ) Bei der Neuverteilung erkennt Tomcat die Löschung (Rückgängigmachung) Ihrer Anwendung. Daher startet er einen Bereinigungsprozess, bei dem auch das Verzeichnis und die xml-Datei gelöscht werden. Dies ist unabhängig

• g
• e
• i

I

S

Y

I

Answer 5

Das im Titel beschriebene allgemeine Thema wird abgedeckt durch Neuverteilung aus dem Krieg ohne Löschen des Kontexts was zur Zeit noch offen ist.

Es gibt einen anerkannten Unterschied zwischen der erneuten Bereitstellung, bei der der Kontext nicht gelöscht wird, und der Bereitstellung nach der Aufhebung der Bereitstellung, bei der die Aufhebung der Bereitstellung den Kontext löscht. Die Dokumentation war veraltet, und die grafische Benutzeroberfläche des Managers unterstützt immer noch keine erneute Bereitstellung.