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

Question

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

Однако теперь я хочу, чтобы установить эти сервлеты в несколько экземпляров tomcat автоматически с помощью RPM. RPM сначала скопирует WARs в каталог webapps и банки для фабрики в каталог common/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> 

/context.xml файл META-INF В всей сервлета

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

Answer 1

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

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

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

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

Удачи вам!

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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