Распространенные в JNDI ресурсы в Tomcat

Я запускаю несколько приложений сервлетов в Tomcat (5.5). Все сервлеты используют общий заводской ресурс, который используется совместно с помощью JNDI. На данный момент я могу заставить все работать, включив заводской ресурс в качестве GlobalNamingResource в /conf/server.xml-файл, а затем имеющий мета-INF/контекст каждого сервлета.xml-файл включает ссылку на ресурс. Ниже приведены фрагменты из XML-файлов. Примечание: Я не так хорошо знаком с tomcat, поэтому я не говорю, что это хорошая конфигурация!!!

однако теперь я хочу иметь возможность устанавливать эти сервлеты в несколько экземпляров tomcat автоматически с помощью RPM. RPM сначала скопирует войны в каталог webapps, а банки для фабрики в общий каталог/lib (что нормально). Но также необходимо убедиться, что заводской ресурс включен в качестве ресурса для всех сервлетов.

каков наилучший способ добавить ресурс глобально? Я не слишком увлекаюсь написание сценария, который идет на сервер.XML-файл и добавляет в ресурс таким образом. Есть ли способ добавить несколько серверов.xml-файлы, чтобы я мог написать новое серверное приложение.xml-файл, и он объединит Мои настройки с сервером.в XML? Или, еще лучше добавить этот ресурс JNDI ко всем сервлетам без использования сервера.xml вообще?

p.s. Перезапуск сервера не будет проблемой, поэтому я не возражаю, если изменения не будут подобраны автоматически.

спасибо

фрагмент с сервера.в XML

  <!-- Global JNDI resources -->
  <GlobalNamingResources>

  <Resource name="bean/MyFactory"
                auth="Container"
                type="com.somewhere.Connection"
                factory="com.somewhere.MyFactory"/> 
  </GlobalNamingResources>

весь мета-INF/контекст сервлета.xml-файл

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <ResourceLink global="bean/MyFactory"
                name="bean/MyFactory"
                type="com.somewhere.MyFactory"/>
  </Context>
6
java jndi resources tomcat

4 ответов

начиная с Tomcat 4, рекомендация заключалась в том, чтобы не помещать информацию JNDI в сервер.в XML. Проверка документация Tomcat 5.5:

для Tomcat 5, в отличие от Tomcat 4.х, это Не рекомендуется размещать элементы непосредственно на сервере.XML файл. Это потому что оно делает изменение конфигурации контекста более инвазивный, так как основной conf / server.XML-файл не может быть перезагрузка без перезагрузки Кот.

Я знаю, вы утверждаете, что не заботитесь об этом, но поверьте мне, ваша команда развертывания делает, и команда обслуживания поблагодарит вас позже. Даже если это означает, что вы в конечном итоге благодарите себя.

Если вам нужен параметр JNDI для совместного использования всеми webapps на сервере, вы должны поместить его в файл $CATALINA_HOME/conf/context.XML. По всей вероятности, будет существовать существующий контекст.xml уже в этом месте, но вы должны иметь возможность написать простое приложение для добавьте узлы ресурсов через ваш любимый язык и любой DOM builder поставляется в комплекте с ним. Или, если вы хотите придерживаться командной строки, проверьте в этой статье, который дает несколько сценариев оболочки XML-обработки, чтобы помочь вам.

удачи!

1

на самом деле у нас есть случай, когда мы не можем поместить (например) конфигурацию jdbc в войну: клиент никогда не даст нам знать имя пользователя и пароль для производственного сервера, поэтому нам пришлось определить источник данных в глобальной конфигурации сервера и поместить ссылку в контекст.xml приложения, как и op. Глобальная конфигурация может быть помещена либо в сервер.xml или в контексте tomcat.в XML (кажется, что второй подход является одним preferend на платформе Windows).

1

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

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

поработав над проектами, где я развернул/общие / lib банки и общие ресурсы, и был укушен ими запутанными и тонкими способами (я в конечном итоге узнал, что это всегда моя собственная вина кстати, не обвиняя Tomcat здесь), я теперь предпочитаю полностью защитный подход к моим webapps: держите их полностью независимыми.

но, конечно, я не полностью знаю ваши обстоятельства, просто некоторые предложения.

0

это то, что я бы сделал, я использую Maven 3, я бы поставил server.xml в своем resources каталог или какой-либо другой каталог я могу запустить filter on и динамически заменять и генерировать соответствующий server.xml когда я делаю пакет. Затем вы можете использовать Maven-rpm-plugin и автоматизировать генерацию rpm.

0