Общие ресурсы JNDI в Tomcat

Question

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

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

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

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

Спасибо

Фрагмент из server.xml

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

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

Файл META-INF / context.xml всего сервлета

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

Answer 1

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

Answer 2

Начиная с Tomcat 4, рекомендуется не помещать какую-либо информацию JNDI в файл server.xml . Проверьте документацию Tomcat 5.5 :

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

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

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

Удачи!

Answer 3

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

Answer 4

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

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

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

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