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

Question

Документация говорит, что если у вас есть файл контекста здесь:

$CATALINA_HOME/conf/Catalina/localhost/myapp.xml

, он НЕ будет заменен файлом контекста здесь:

mywebapp.war/META-INF/context.xml

Здесь написано: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

Только если контекстный файл для приложения не существует в каталоге $ CATALINA_BASE / conf / [enginename] / [имя_хоста] /, в отдельном файле в /META-INF/context.xml внутрифайлы приложения.

Но каждый раз, когда я заново развертываю войну, он заменяет этот файл myapp.xml на /META-INF/context.xml!

Почему он это делает икак я могу избежать этого?

Спасибо

Answer 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

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

Answer 2

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

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

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

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

     chmod a-w TOMCATHOME/conf/Catalina/localhost
  

  Вуаля!Добро пожаловать.

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

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

Answer 3

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

Undeployment удаляет 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.

Answer 4

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

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

Не знаю почему, но 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)

Если бы кто-то мог сказать, что это за «внешние ресурсы», это обычно решало бы проблему.

Answer 5

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

Я нашел обходной путь, который решил эту проблему для меня:Файл META-INF / context.xml в вашем веб-приложении, содержащий

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

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

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