Назад | Перейти на главную страницу

Почему tomcat нравится удалять мой файл context.xml?

Я разрабатываю веб-приложение Java на работе и (очевидно) должен запускать его локально во время разработки. Я разобрался с документами Tomcat и у меня есть подходящий файл context.xml в /etc/tomcat6/Catalina/localhost/ но время от времени Tomcat решает удалить его! Это означает, что мне нужно вернуть его и перезапустить Tomcat.

Почему он это делает? Я искал об этом документы Tomcat и не стал мудрее.

(О да, это на самом деле не называется context.xml но owners.xml так как это префикс пути HTTP для этого приложения.)

Обновить

Теперь я видел, как Tomcat удаляет файл пока Tomcat работал. Думаю, мне нужно сообщить об ошибке ...

Краткое резюме: существует несколько условий (например, изменение файла war, удаление веб-приложения или замена его новым содержимым), при которых tomcat отменяет развертывание контекста, включая удаление файла контекста.

подробности: Выполняет или не выполняет tomcat автоматическое развертывание (означает проверку изменений в вашем дескрипторе .xml, а также проверку изменений в каталоге webapp) определяется:

  1. server.xml находится в разделе $ CATALINA_HOME / conf / server.xml:

    <Host name = "localhost" appBase = "webapps" unpackWARs = "true" autoDeploy = "истина" xmlValidation = "false" xmlNamespaceAware = "false">

  2. Вы также можете установить это свойство в своем файле контекста, перегрузив значение

Цитата из документа для случаев, когда autoDeploy = true может вызвать удаление вашего файла контекста:

  • Удаление файла WAR приведет к отмене развертывания приложения. с удалением любого связанного расширенного каталога, файла контекста и рабочий каталог.
  • Удаление каталога приведет к отмене развертывания приложения. с удалением любого связанного файла контекста и рабочий каталог.
  • Обновление файла WAR приведет к отмене развертывания приложения. с удалением любого связанного расширенного каталога, файла контекста и рабочий каталог.
  • Обновление каталога (не содержимого каталога) приведет к отмене развертывания приложения. с удалением любого связанного файла контекста и рабочий каталог.

Исчерпывающие детали: http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment

если ты не хочу autoDeploy Например, в производственной среде вы можете учитывать следующие атрибуты в файле контекста conf / Catalina / localhost:

  • autoDeploy = "ложь"
  • и deployXML = "false"

autoDeploy = "false" может не работать отдельно, потому что приложение context.xml (в META-INF) может переопределить настройки server.xml для autoDeploy.

  • META-INF / context.xml приложения будет использоваться в среде разработки с autoDeploy.
  • Контекст conf / Catalina / localhost в производственной среде без autoDeploy.

документация по атрибуту deployXML документацию по атрибутам стоит прочитать (§ Стандартная реализация).

Исчерпывающий случай пользователя autoDeploy, и когда контекст удален: то есть приложение не развернуто, пользовательский случай документирован можно найти Вот.

Не могу ответить на Зачем немного.

Тем не мение, Эта ссылка заявляет, что вы можете остановить это, установив autoDeploy="false" в server.xml

Я честно не знаю, почему Tomcat делает это, но попробуйте добавить следующий атрибут XML в свой элемент контекста

reloadable="false"

Итак, ваш контекст может выглядеть примерно так:

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

Это должно помешать Tomcat удалить файл

Я понимаю, что это старая ветка, но я подумал, что поделюсь тем, что нашел для решения этой проблемы ...

У меня была такая же проблема с моим файлом context.xml для моей настольной версии tomcat, который затирался каждый раз, когда я развертывал новую копию файла war для своего приложения.

Проблема была связана с тем, что я вносил изменения в этот файл непосредственно в файловой системе. Проблема была устранена путем редактирования файла context.xml через мой редактор Eclipse. Внутри моего Eclipse есть проект «серверы», который после его расширения вы можете увидеть несколько файлов, таких как context.xml и server.xml. Похоже, что если вы изменяете файлы отсюда, а не в файловую систему, ваши изменения сохраняются.

Я нашел это решение в следующем потоке: https://www.liferay.com/community/forums/-/message_boards/message/16511799

Надеюсь, это поможет кому-то другому!

-StephenS

Общая проблема, описанная в заголовке, рассматривается в Повторное развертывание с войны без удаления контекста что все еще остается открытым вопросом.

Существует общепризнанное различие между повторным развертыванием, которое не удаляет контекст, и развертыванием после отмены развертывания, при котором удаление удаляет контекст. Документация устарела, а графический интерфейс менеджера по-прежнему не поддерживает повторное развертывание.

Иногда необходимо иметь разные значения для приложения на сервере, например, путь для хранения загруженных файлов. В среде разработчика mabe у нас есть что-то вроде этого:

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

Но на сервере путь другой:

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

У меня тоже такая же проблема: tomcat удаляет context.xml (meapp.xml) из conf / Catalina / localhost

Чтобы решить эту проблему, я использую context.xml.default, по тому же пути я создаю файл с именем context.xml.default и внутри помещаемой конфигурации, которую я хочу сохранить:

 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>

Таким образом, при повторном развертывании приложения параметры подтверждения все еще присутствуют.