Dlaczego tomcat lubi usuwać mój plik context.xml?

Zajmuję się tworzeniem internetowej aplikacji Java w pracy i (oczywiście) muszę ją uruchamiać lokalnie podczas programowania. Opracowałem dokumentację Tomcat i mam odpowiedni plik context.xml, /etc/tomcat6/Catalina/localhost/ale co jakiś czas Tomcat decyduje się go usunąć! Co oznacza, że ​​muszę go odłożyć i ponownie uruchomić Tomcat.

Dlaczego to robi? Przeszukałem na ten temat dokumenty Tomcat i nie jestem mądrzejszy.

(Och tak: nie jest tak naprawdę wywoływane, context.xmlale owners.xmlponieważ jest to przedrostek ścieżki HTTP dla tej aplikacji).

Aktualizacja

Widziałem teraz, jak Tomcat usuwa plik, gdy Tomcat jest uruchomiony . Myślę, że muszę zgłosić błąd ...

Szybkie podsumowanie : istnieje kilka warunków (takich jak zmiana pliku wojny, usunięcie aplikacji internetowej lub zastąpienie jej nową zawartością), w których tomcat usunie kontekst, w tym usunięcie pliku kontekstu.

Szczegóły : To, czy tomcat wykonuje lub nie wykonuje autoDeployment (oznacza sprawdzanie zmian w deskryptorze .xml, a także sprawdzanie zmian w katalogu aplikacji WWW) zależy od:

1. server.xml zlokalizowany w sekcji $ CATALINA_HOME / conf / server.xml:

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

2. Możesz także ustawić tę właściwość w pliku kontekstowym, przeciążając wartość

Cytując dokument w przypadkach, gdy autoDeploy = true może spowodować usunięcie pliku kontekstu:

• Usunięcie pliku WAR spowoduje uruchomienie aplikacji z usunięciem dowolnego powiązanego rozszerzonego katalogu, pliku kontekstowego i katalogu roboczego.
• Usunięcie katalogu spowoduje cofnięcie wdrożenia aplikacji wraz z usunięciem dowolnego powiązanego pliku kontekstowego i katalogu roboczego.
• Aktualizacja pliku WAR spowoduje uruchomienie aplikacji z usunięciem powiązanego rozszerzonego katalogu, pliku kontekstowego i katalogu roboczego.
• Aktualizacja katalogu (nie zawartości katalogu) spowoduje uruchomienie aplikacji z usunięciem dowolnego powiązanego pliku kontekstowego i katalogu roboczego.

Wyczerpujące szczegóły : http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment

Jeśli nie chcesz funkcji autoDeploy , na przykład w środowiskach produkcyjnych, możesz rozważyć następujące atrybuty w pliku kontekstowym conf / Catalina / localhost:

• autoDeploy = "false"
• i deployXML = „false”

autoDeploy = „fałsz” może nie działać sam, ponieważ aplikacja context.xml (w META-INF) może zastąpić ustawienia server.xml funkcji autoDeploy.

• Meta-INF / context.xml aplikacji będzie używany w środowisku programistycznym z autoDeploy
• Kontekst conf / Catalina / localhost w produkcji, bez autoDeploy.

Warto zapoznać się z dokumentacją atrybutów dokumentacji atrybutów XML (§ Standardowe wdrożenie).

Wyczerpująca sprawa użytkownik autoDeploy, a gdy kontekst jest usuwany: czyli aplikacja nieaktywnej, użytkownik jest udokumentowany przypadek można znaleźć tutaj .

Nie mogę odpowiedzieć na pytanie dlaczego .

Jednak ten link mówi, że możesz to zatrzymać, ustawiając autoDeploy="false"wserver.xml

Szczerze mówiąc, nie wiem, jakie są tego powody, ale spróbuj dodać następujący atrybut XML do elementu kontekstu

reloadable="false"

Twój kontekst może wyglądać mniej więcej tak:

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

To powinno powstrzymać Tomcat przed usunięciem pliku

Zdaję sobie sprawę, że to stary wątek, ale pomyślałem, że podzielę się tym, co znalazłem, aby rozwiązać ten problem ...

Miałem dokładnie ten sam problem z plikiem kontekstowym.xml mojej komputerowej wersji tomcata, który był blokowany za każdym razem, gdy wdrażałem nową kopię pliku war dla mojej aplikacji.

Problem wynikał z tego, że wprowadzałem zmiany do tego pliku bezpośrednio w systemie plików. Rozwiązaniem problemu była edycja pliku context.xml za pomocą mojego edytora Eclipse. Wewnątrz mojego Eclipse znajduje się projekt „serwerów”, który po rozwinięciu wyświetla garść plików, takich jak context.xml i server.xml. Wygląda na to, że jeśli zmodyfikujesz pliki stąd zamiast wychodzić do systemu plików, zmiany zostaną zachowane.

Znalazłem to rozwiązanie w następującym wątku: https://www.liferay.com/community/forums/-/message_boards/message/16511799

Mam nadzieję, że to pomaga komuś innemu!

-StephenS

Ogólny problem opisany w tytule jest objęty ponownym wdrożeniem z wojny bez usuwania kontekstu, który jest nadal otwartym problemem.

Zauważono rozróżnienie między ponownym wdrożeniem, które nie usuwa kontekstu, a wdrożeniem po odinstalowaniu, w przypadku którego odinstalowanie usuwa kontekst. Dokumentacja była nieaktualna, a GUI menedżera nadal nie obsługuje ponownego wdrażania.

Czasami konieczne jest posiadanie różnych wartości dla aplikacji na serwerze, na przykład ścieżka do przechowywania przesłanych plików. W środowisku deweloperskim mabe mamy coś takiego:

<?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>

Ale na serwerze ścieżka jest inna:

<?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>

Mam również ten sam problem, tomcat usuwa plik context.xml (meapp.xml) z conf / Catalina / localhost

Aby rozwiązać, używam kontekst.xml.default, w tej samej ścieżce tworzę plik o nazwie context.xml.default i wewnątrz konfiguracji put, którą chcę trzymać:

 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>

Tak więc, kiedy ponownie wdrażam aplikację, potwierdzone parametry wciąż tam są.