Зачем использовать файлы Tomcat context.xml для объявления ресурсов DBCP?

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

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

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

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

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

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

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


person brabster    schedule 09.06.2009    source источник


Ответы (2)


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

person Gandalf    schedule 10.06.2009

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

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

Кстати context.xml может жить вне ВОЙНЫ (см. документацию Tomcat об этом или фрагмент ниже):

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

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

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

  • В файле $CATALINA_BASE/conf/context.xml: информация об элементе контекста будет загружена всеми веб-приложениями.
  • В файле $CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default: информация об элементе Context будет загружаться всеми веб-приложениями этого хоста.
person Adam Gent    schedule 31.05.2015