Почему tomcat заменяет context.xml на повторное развертывание?

Ответ 1

При отмене развертывания часть повторного развертывания удаляет приложение и связанный с ним context.xml.

Если вы используете плагин maven tomcat, вы можете избежать удаления context.xml, если развернете свое приложение с помощью команды, подобной этой:

mvn tomcat:deploy-only -Dmaven.tomcat.update=true

Подробнее здесь: https://tomcat.apache.org/maven-plugin-2.0-beta-1/tomcat7-maven-plugin/deploy-only-mojo.html

Вы также можете использовать deploy-only с параметром mode для развертывания context.xml.

Ответ 2

Короткий ответ:

Просто создайте директорию TOMCATHOME/conf/Catalina/localhost только для чтения и продолжайте читать для получения дополнительной информации:

• Для режима быстрого развертывания (динамический веб-проект Eclipse, прямой Tomcat соединение и т.д.) на локальном/не общего сервера Tomcat вы можете просто определить свой источник данных JDBC (или любой другой другой "веб-ресурс" ) с использованием файла META-INF/context.xml внутри WAR. Легко и быстро в вашей локальной среде, но не подходит для постановки, контроля качества или производство.

• Для режима построения развертывания (обычно для этапа, QA или prod) JDBC источники данных и другие данные "веб-ресурсов" определяются QA/производственная группа, а не команда разработчиков. Поэтому они должен быть указан на сервере Tomcat, а не внутри файла WAR больше. В этом случае укажите их в файле TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml (изменить Каталина движком и localhost для хоста, а CONTEXT соответствующим контекстом). Однако, Tomcat удалит этот файл для каждого развертывания. Чтобы предотвратить это удаление, просто сделайте эту директорию только для чтения; в Linux вы можете ввести:

     chmod a-w TOMCATHOME/conf/Catalina/localhost
  

  Voila! Ваше приветствие.

Длинный ответ

• По историческим причинам Tomcat позволяет вам определять веб-ресурсы (источники данных JDBC и другие) в четырех в разных местах (прочитайте четыре разных файла) в очень определенном порядке приоритета, если вам приходится определять один и тот же ресурс несколько раз. Те, которые указаны в короткий ответ выше, более подходящий в настоящее время для каждой цели, хотя вы все еще можете используйте другие (нет... вы, вероятно, не хотите). я не собираюсь обсудите других здесь, если кто-то не попросит об этом.

Ответ 3

В tomcat7, также autoDeploy = false, файл будет удален при распаковке. Это документировано, а не ошибка (хотя он избегает хороших автоматизированных развертываний с фиксированной конфигурацией на стороне сервера).

Я нашел обходное решение, которое решило проблему для меня:

• создайте файл META-INF/context.xml в вашем webapp, который содержит
• на сервере создайте второй контекст "/config-context" в файле server.xml и разместите там все параметры конфигурации на стороне сервера.
• в приложении используйте context.getContext( "/config-context" ). getInitParameter (...) для доступа к конфигурации там.

Это позволяет настроить конфигурацию каждого хоста, не зависящую от развернутой войны.

Также должно быть возможно добавить конфигурации для каждого контекста, добавив такие контексты, как "/config-context-MYPATH". В вашем приложении вы можете использовать контекстный путь приложения, чтобы вычислить путь к контексту конфигурационного приложения.

Ответ 4

В соответствии с документацией (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files) при повторном развертывании tomcat обнаруживает удаление (undeploy) вашего приложения. Таким образом, он начнет процесс очистки, удалив также каталог и xml. Это не зависит от автоматического развертывания - так это произойдет при перераспределении через менеджера и изменении войны. Есть 3 исключения:

• глобальные ресурсы никогда не удаляются.
• внешние ресурсы никогда не удаляются.
• если WAR или DIR были изменены, тогда файл XML удаляется если copyXML истинно и deployXML истинно

Я не знаю почему, но copyXML = "false" deployXML = "false" не поможет.

Во-вторых: создание каталога только для чтения только делает tomcat бросать исключение и не запускаться.

Вы можете попробовать объединить файлы $CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml, $CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml и т.д. в $CATALINA_BASE/conf/context.xml( это работает, только если вы убедитесь, что ваше приложение не будет развертывать собственную конфигурацию контекста, например myapp-1.xml)

Если кто-то может сказать, что такое "внешние ресурсы", которые обычно решают проблему.

Ответ 5

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

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

Ответ 6

Передислокация означает две части: отмена развертывания и развертывание.

При развертывании удаляется conf/Catalina/yourhost/yourapp.xml, потому что

 <Host name="localhost" appBase="webapps" unpackWARs="true" 

           autoDeploy="true">      <!-- means autoUndeploy too!!! -->

 </Host>

Измените autoDeploy="false", и у Tomcat больше нет приказа удалить conf/Catalina/yourhost/yourapp.xml.

Существует функция, которая позволяет нам выполнять эти шаги (отменять/развертывать) как один единственный шаг (повторное развертывание), которые не удаляют context.xml. Эта функция доступна через текстовый интерфейс manager, но опция недоступна при использовании html-интерфейса manager. Возможно, вам придется подождать, пока ошибка в tomcat не будет исправлена. Вы можете использовать метод, описанный в этом ответе, в качестве обходного пути.