Зачем использовать файлы context.xml Tomcat для объявления ресурсов DBCP? - PullRequest
2 голосов
/ 09 июня 2009

У меня проблемы с пониманием, почему я бы использовал файл context.xml для объявления ресурса, в моем случае - пула соединений с базой данных. Надеюсь, я изложил факты в следующих аргументах против использования context.xml

  1. Насколько я могу судить, ресурсы объявлено в /META-INF/context.xml доступны только в пределах контекст, поэтому нет причин делать так что делиться ресурсами.

  2. Объявление соединения ресурс пула таким образом создает зависимость от контейнера загрузчик классов, так что если я сделаю так и, например, желаю чтобы изменить мои драйверы базы данных, я необходимо перезапустить контейнер, а не только мой контекст.

  3. Я также создаю зависимость от Содержащие вещи, такие как JNDI, которые делает самостоятельное тестирование трикером.

  4. Наконец, я должен прыгнуть построение обручи для переключения ресурсов между испытанием и производством ресурсы например.

Ни одна из этих проблем не является непреодолимой, но на бумаге, безусловно, гораздо проще просто создать пул соединений и подключить его к моей контекстной области.

Я хотел бы знать, при каких обстоятельствах файлы context.xml являются правильным ответом?

Ответы [ 2 ]

1 голос
/ 31 мая 2015

Другая причина, по которой вы можете захотеть использовать context.xml, заключается в переопределении параметров инициализации сервлета, которые затем могут использоваться для настройки любого количества вещей, включая, возможно, ваш DBCP, управляемый чем-то вроде Spring.

Это может быть предпочтительнее системных свойств и / или переменных среды, поскольку вы можете развернуть несколько копий одной и той же WAR в одном контейнере без изменения WAR, и их конфигурация не будет перекрываться.

Кстати, context.xml может жить за пределами WAR (см. Документацию Tomcat по этому вопросу или фрагмент ниже):

Отдельные элементы контекста могут быть явно определены:

  • В отдельном файле в /META-INF/context.xml внутри файлов приложения. Опционально (на основе атрибута hostX copyXML) это может быть скопировано в $ CATALINA_BASE / conf / [enginename] / [hostname] / и переименован в базовое имя файла приложения плюс расширение «.xml».
  • В отдельных файлах (с расширением «.xml») в каталоге $ CATALINA_BASE / conf / [enginename] / [hostname] /. Контекст путь и версия будут получены из базового имени файла ( имя файла без расширения .xml). Этот файл всегда будет приоритет над любым файлом context.xml, упакованным в веб-приложение Каталог META-INF.
  • Внутри элемента Host в основном файле conf / server.xml.

Могут быть определены элементы контекста по умолчанию, которые применяются к нескольким веб Приложения. Конфигурация для отдельного веб-приложения переопределит все настроен в одном из этих значений по умолчанию. Любые вложенные элементы, например элементы, которые определены в контексте по умолчанию, будут создается один раз для каждого контекста, к которому применяется значение по умолчанию. Они будут не может быть разделен между элементами контекста.

  • В файле $ CATALINA_BASE / conf / context.xml: информация об элементе Context будет загружена всеми веб-приложениями.
  • В файле $ CATALINA_BASE / conf / [enginename] / [hostname] /context.xml.default: информация об элементе Context будет загружена всеми веб-приложениями этого хозяина.
1 голос
/ 10 июня 2009

Единственная действительная причина, которую я видел, заключается в том, что вы хотите, чтобы Tomcat мог использовать ваш пул соединений для чего-то похожего на обычные вызовы аутентификации пользователя, если вы настроили использование контекста JDBC UserAuth, тогда вы можете захотеть, чтобы Tomcat есть пул соединений.

...