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

Документация говорит, что если у вас есть файл контекста здесь:Почему tomcat заменяет context.xml на повторное развертывание?

$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!

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

Thanx

источник

2010-10-27 artemb

Вы развертываете вручную или плагин IDE? – BalusC

Лично я бы не поставил context.xml на сервер приложений. Я не потому, что редко могу зависеть от доступа к этому файлу. Обычно я держу его локальным в файле WAR. – duffymo

Я развертываю вручную, помещая mywebapp.war в $ CATALINA_HOME/webapps. Я сохраняю свои настройки по умолчанию в WAR, но я хочу иметь возможность изменять эти параметры для каждого экземпляра без изменения самой войны, поэтому я хочу, чтобы мой контекст в каталоге conf не изменялся – artemb

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

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

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

Больше информации здесь: http://mojo.codehaus.org/tomcat-maven-plugin/deploy-only-mojo.html

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

источник

2011-12-12 10:05:12 petro

Для следующих людей: 'mvn tomcat7: deploy-only -Dmaven.tomcat.update = true -Dmaven.tomcat.mode = both -Dmaven.tomcat.contextFile =/foo/context.xml' делает трюк. Грустный ... но эффективный в tomcat7. –

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

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

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

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

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

источник

2012-10-04 15:24:27

Почему основные разработчики tomcat настолько не осведомлены о развертывании лучших практик? Я потерял в основном ночь, чтобы получить обходной путь здесь, и все работы вокруг являются анти-шаблонами, но разработчики TC находятся в отрицании и не признают, что это разумный подход к установке JNDI-свойств и источников на хосте, а не компиляция их в СКМ и войну. https://issues.apache.org/bugzilla/show_bug.cgi?id=34840 –

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

Просто сделать TOMCATHOME/CONF/Каталина/LOCALHOST реж только для чтения, и продолжайте чтение для более подробной информации:

Для режима быстрого развертывания (Динамический веб-проект Eclipse, прямое подключение Tomcat и т. Д.) На локальном/неэмиссионном сервере Tomcat вы можете просто определить свой источник данных JDBC (или любой другой другой «веб-ресурс») с помощью META-INF/context.xml файл в файле WAR. Легко и быстро в вашей локальной среде, но не подходит для постановки, QA или .
Для режима сборки развертывания (обычно для постановки, QA, или прод), JDBC источники данных и детали других «веб-ресурсов» определяются QA/производственной команды, а не команда разработчиков больше. Поэтому они должны быть указаны на сервере Tomcat, а не в файле WAR . В этом случае указать их в файле TOMCATHOME/конф/Каталина/локальной/context.xml (изменить Catalina двигателя и LOCALHOST хоста и КОНТЕКСТОМ вашего контекст соответственно) , Однако, Tomcat удалит этот файл при каждом развертывании. Чтобы предотвратить удаление , просто сделайте этот каталог только для чтения; В Linux вы можете набрать:
```
chmod a-w TOMCATHOME/conf/Catalina/localhost 
```
вуаля! Пожалуйста.

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

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

источник

2015-03-19 18:00:06 user4691115

Я попрошу об этом ;-) – djKianoosh

Это не сработает, если включен autodeploy для tomcat, и вы используете tomcat7: undeploy он будет жаловаться что он не может удалить файл дескриптора контекста – Chad

С помощью этой опции мои развертывания завершаются ошибкой с сообщением об ошибке «Невозможно вызвать диспетчер Tomcat:« Сброс соединения »по причине, упомянутой в комментарии Чада. Вместо этого я использовал параметр, используя context.xml из WEB-INF и дополнительного (внешнего) ресурса jndi с сервера.xml, как описано в первом ответе [здесь] (http://stackoverflow.com/questions/7142365/how-to-provide-a-context-configuration-for-a-web-application-in-tomcat) – tareq

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

глобальных ресурсов никогда не удаляются
внешних ресурсов никогда не удаляются
если WAR или DIR был изменен, то файл XML удаляется только если copyXML верно и 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)

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

источник

2015-11-10 22:45:58 BTakacs

Реинвестирование означает две части: развертывание и развертывание.

свёртывание удаляет 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.

источник

2017-02-15 22:25:01

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

ответ

Смежные вопросы