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

24

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

staticsan
źródło
Masz ten problem. Wygląda na to, że zastąpienie wojny powoduje cofnięcie aplikacji, co powoduje usunięcie pliku kontekstu. Nie mam obejścia, ale chciałbym mieć taki, który jest wygodniejszy niż do
ponownego załadowania

Odpowiedzi:

18

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

Jan Zyka
źródło
To nie jest pełna odpowiedź - patrz serverfault.com/faq#deletion
Jenny D mówi Przywróć Monikę
:) proszę, pomóż sobie (wydaje się, że podświetlanie składni działa nieco inaczej niż w przepełnieniu stosu, który usunął wcześniej część odpowiedzi)
Jan Zyka
Chodzi o to, że po dodaniu linku cel łącza może zniknąć, co uczyni odpowiedź bezużyteczną. Właśnie dlatego serverfault.com zachęca do opublikowania rzeczywistej odpowiedzi zamiast samego linku. A kiedy skomentowałem, reszta tekstu nie była widoczna. Nadal zalecałbym opublikowanie pełniejszej odpowiedzi niż krótkie podsumowanie linku.
Jenny D mówi Przywróć Monikę
1
To po prostu nieprawda. Oryginalna odpowiedź zawierała (i nadal zawiera) krótkie streszczenie tego, co można znaleźć pod linkiem. Bez linku odpowiedź nadal ma sens i wraz z linkiem można znaleźć szczegóły.
Jan Zyka
Ale nie planowałem być obraźliwy, więc przepraszam, jeśli tak to brzmiało :) Nie jestem zbytnio zainteresowany tą siecią, po prostu rozwiązałem to samo i chciałem się nią podzielić.
Jan Zyka
5

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 .

Gabriel Glenn
źródło
2

Nie mogę odpowiedzieć na pytanie dlaczego .

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

JoseK
źródło
1
Pod tomcat7 autoDeploy = "false" nie robi różnicy :(
Joseph Lust
1

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

Koleś
źródło
Niestety utrudnia to programowanie, ponieważ musiałbym ponownie uruchamiać Tomcat po każdej kompilacji.
staticsan
sprawdź jrebel, aby pomóc w tym w rozwoju: zeroturnaround.com/jrebel
harmanjd
0

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

użytkownik216156
źródło
0

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.

użytkownik250343
źródło
-1

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ą.

Larry
źródło