Почему 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 = "true" 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" может работать не один, потому что application 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>

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