Warum löscht Tomcat gerne meine context.xml-Datei?


24

Ich entwickle eine webbasierte Java-Anwendung bei der Arbeit und muss sie (offensichtlich) während der Entwicklung lokal ausführen. Ich habe die Tomcat-Dokumente herausgefunden und habe eine passende context.xml-Datei darin, /etc/tomcat6/Catalina/localhost/aber Tomcat beschließt von Zeit zu Zeit, sie zu löschen! Das heißt, ich muss es zurücksetzen und Tomcat neu starten.

Warum macht es das? Ich habe in den Tomcat-Dokumenten nach Informationen gesucht und bin nicht klüger.

(Oh ja: Es wird eigentlich nicht aufgerufen, context.xmlaber owners.xmlda dies das HTTP-Pfadpräfix für diese Anwendung ist.)

Aktualisieren

Ich habe jetzt gesehen, wie Tomcat die Datei löschte, während Tomcat lief . Ich glaube, ich muss einen Fehler melden ...


Habe dieses Problem an. Scheint, als ob wenn Sie Ihren Krieg ersetzen, die App nicht mehr bereitgestellt wird, wodurch die Kontextdatei gelöscht wird. Ich habe keine Umgehungsmöglichkeit
artemb

Antworten:


18

Kurzzusammenfassung : Es gibt verschiedene Bedingungen (z. B. Ändern der War-Datei, Löschen der Webanwendung oder Ersetzen durch neuen Inhalt), unter denen Tomcat die Bereitstellung des Kontexts aufhebt, einschließlich des Entfernens der Kontextdatei.

Details : Ob Tomcat AutoDeployment durchführt oder nicht (dies bedeutet, dass Sie nach Änderungen in Ihrem XML-Deskriptor suchen und Änderungen im Webapp-Verzeichnis überprüfen), hängt von folgenden Faktoren ab:

  1. server.xml im Abschnitt $ CATALINA_HOME / conf / server.xml:

    <Hostname = "localhost" appBase = "webapps" unpackWARs = "true" autoDeploy = "true" xmlValidation = "false" xmlNamespaceAware = "false">

  2. Sie können diese Eigenschaft auch in Ihrer Kontextdatei festlegen, um den Wert zu überladen

Das Zitieren des Dokuments für Fälle, in denen autoDeploy = true ist, kann zum Entfernen Ihrer Kontextdatei führen:

  • Durch das Löschen einer WAR-Datei wird die Bereitstellung der Anwendung aufgehoben , und alle zugehörigen erweiterten Verzeichnisse, Kontextdateien und Arbeitsverzeichnisse werden entfernt.
  • Durch das Löschen eines Verzeichnisses wird die Bereitstellung der Anwendung aufgehoben, und alle zugehörigen Kontextdateien und Arbeitsverzeichnisse werden entfernt.
  • Durch das Aktualisieren einer WAR-Datei wird die Bereitstellung der Anwendung aufgehoben , und alle zugehörigen erweiterten Verzeichnisse, Kontextdateien und Arbeitsverzeichnisse werden entfernt.
  • Das Aktualisieren eines Verzeichnisses (nicht des Verzeichnisinhalts) löst eine Aufhebung der Bereitstellung der Anwendung aus, wobei alle zugehörigen Kontextdateien und Arbeitsverzeichnisse entfernt werden.

Ausführliche Details : http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment


Dies ist keine vollständige Antwort - siehe serverfault.com/faq#deletion
Jenny D sagt Reinstate Monica

:) Bitte helfen Sie sich selbst (scheint die Syntax-Hervorhebung funktioniert etwas anders als in Stackoverflow, die einen Teil der Antwort zuvor gelöscht)
Jan Zyka

Die Sache ist, dass, wenn Sie nur einen Link hinzufügen, das Ziel des Links möglicherweise verschwindet, was die Antwort unbrauchbar macht. Deshalb fordert serverfault.com Sie auf, die eigentliche Antwort anstelle nur des Links zu posten. Und als ich das kommentierte, war der Rest des Textes nicht sichtbar. Ich würde immer noch empfehlen, eine vollständigere Antwort zu posten, anstatt eine kurze Zusammenfassung des Links.
Jenny D sagt Reinstate Monica

1
Das stimmt einfach nicht. Die ursprüngliche Antwort enthielt (und tut es immer noch) eine kurze Zusammenfassung dessen, was Sie unter dem Link finden können. Ohne den Link macht die Antwort immer noch Sinn und zusammen mit dem Link finden Sie Details.
Jan Zyka

Aber ich hatte nicht vor, beleidigend zu sein. Es tut mir leid, wenn es sich so anhört.
Jan Zyka

5

Wenn Sie beispielsweise in Produktionsumgebungen keine AutoDeploy- Funktion wünschen , können Sie die folgenden Attribute in der Kontextdatei conf / Catalina / localhost berücksichtigen:

  • autoDeploy = "false"
  • und deployXML = "false"

autoDeploy = "false" funktioniert möglicherweise nicht alleine, da die Datei context.xml (in META-INF) die server.xml-Einstellungen von autoDeploy überschreiben kann.

  • Die Datei META-INF / context.xml der Anwendung wird in der Entwicklungsumgebung mit autoDeploy verwendet
  • Der Kontext conf / Catalina / localhost in der Produktion ohne autoDeploy.

Dokumentation der deployXML-Attribute Die Dokumentation der Attribute ist lesenswert (§ Standardimplementierung).

Erschöpfender AutoDeploy Benutzer Fall und wenn der Kontext entfernt wird : dh Anwendung nicht entfalteten, wird der Benutzer Fall dokumentiert findet sich hier .


2

Kann das Warum- Bit nicht beantworten .

Allerdings Dieser Link erklärt Sie können dies ausschalten , indem Sie die Einstellung autoDeploy="false"inserver.xml


1
Unter tomcat7 macht autoDeploy = "false" keinen Unterschied :(
Joseph Lust

1

Ich weiß ehrlich gesagt nicht, was der Grund dafür ist, dass Tomcat dies tut, aber versuchen Sie, Ihrem Kontextelement das folgende XML-Attribut hinzuzufügen

reloadable="false"

Ihr Kontext könnte also so aussehen:

<Context path="/" docBase="/some/path/name" reloadable="false">
<!-- Context related stuff -->
</Context>

Dies sollte Tomcat davon abhalten, die Datei zu löschen


Leider macht das die Entwicklung schwieriger, da ich Tomcat nach jedem Build neu starten müsste.
Staticsan

checkout jrebel hilft bei der entwicklung: zeroturnaround.com/jrebel
harmanjd

0

Mir ist klar, dass dies ein alter Thread ist, aber ich dachte, ich würde teilen, was ich gefunden habe, um dieses Problem zu beheben ...

Ich hatte genau das gleiche Problem mit meiner context.xml-Datei für meine Desktop-Version von Tomcat, die jedes Mal, wenn ich eine neue Kopie der War-Datei für meine Anwendung bereitstellte, überlastet wurde.

Das Problem lag daran, dass ich Änderungen an dieser Datei direkt im Dateisystem vorgenommen habe. Das Problem wurde behoben, indem die Datei context.xml über meinen Eclipse-Editor bearbeitet wurde. In meiner Eclipse gibt es ein "Server" -Projekt, in dem nach dem Erweitern eine Handvoll Dateien angezeigt werden, z. B. context.xml und server.xml. Wenn Sie die Dateien von hier aus ändern, anstatt in das Dateisystem zu wechseln, werden Ihre Änderungen anscheinend beibehalten.

Ich habe diese Lösung in folgendem Thread gefunden: https://www.liferay.com/community/forums/-/message_boards/message/16511799

Ich hoffe das hilft jemand anderem!

-StephenS


0

Das allgemeine Problem, wie es im Titel beschrieben wird, wird durch die erneute Bereitstellung aus dem Krieg abgedeckt, ohne den Kontext zu löschen, der zu diesem Zeitpunkt immer noch ein offenes Problem darstellt.

Es gibt einen anerkannten Unterschied zwischen der erneuten Bereitstellung, bei der der Kontext nicht gelöscht wird, und der Bereitstellung nach der Nichtbereitstellung, bei der die Nichtbereitstellung den Kontext löscht. Die Dokumentation war veraltet und die Manager-GUI unterstützt die erneute Bereitstellung immer noch nicht.


-1

Manchmal ist es notwendig, unterschiedliche Werte für die App auf dem Server zu haben, zum Beispiel einen Pfad zum Speichern hochgeladener Dateien. In der Entwicklerumgebung haben wir ungefähr Folgendes:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" reloadable="false">
     <Parameter name="rutaTrabajo" value="C:\Larry\Proyectos\app\rutaTrabajoxx" override="true"/>
</Context>

Im Server ist der Pfad jedoch anders:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/App/rutaTrabajo" override="true"/>
</Context>

Ich habe auch das gleiche Problem, Tomcat Löschen der context.xml (meapp.xml) aus conf / Catalina / localhost

Zur Lösung verwende ich context.xml.default und erstelle im selben Pfad eine Datei mit dem Namen context.xml.default und in einer Put-Konfiguration, die ich behalten möchte:

 cat context.xml.default
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/ParkiMeApp/rutaTrabajo" override="true"/>
</Context>

Wenn Sie also die App erneut implementieren, bleiben die confir-Parameter erhalten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.