У нашей команды было то же самое требование - разделять компоненты Spring между несколькими WAR-ами в Tomcat, и, честно говоря, такие ответы, как «Не делай этого», бесполезны.
Требование вытекает из того факта, что у нас есть приложение с несколькими WAR, работающее на Tomcat, и все WAR нуждаются в доступе к одной и той же СУБД для сохранения информации.Мы используем Spring и Hibernate для доступа к RDBM, и все WAR используют одну и ту же схему и в идеале могут использовать одни и те же Hibernate SessionFactory и Spring Manager manager.
Ответ о том, как это сделать, был размещен здесь:
StackOverflow: общий доступ к ApplicationContext в EAR
и для подведения итогов выполните следующие действия:ваш web.xml:
<context-param>
<param-name>parentContextKey</param-name>
<param-value>sharedContext</param-value>
</context-param>
<context-param>
<param-name>locatorFactorySelector</param-name>
<param-value>classpath:beanRefContext.xml</param-value>
</context-param>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:yourWarSpecificAppContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
, где beanRefContext.xml содержит:
<beans>
<bean id="sharedContext" class="org.springframework.context.support.ClassPathXmlApplicationContext">
<constructor-arg>
<list>
<value>classpath:yourSharedAppContext.xml</value>
</list>
</constructor-arg>
</bean>
</beans>
При этом Spring ContextSingletonBeanFactoryLocator используется для предоставления и совместного использования родительского контекста (в этомслучай, используя имя "sharedContext").Общий контекст будет лениво загружаться, когда первая WAR ссылается на него.
Все компоненты, на которые вы ссылаетесь в общем контексте, должны быть доступны для всех WAR, что означает, что они не могут быть загружены из WEB-INF / classes или WEB-INF / lib в пределах определенной WAR.Они должны быть предоставлены в общий доступ либо с помощью файла EAR, либо путем помещения jar-файлов, содержащих бины (и зависимости), в общую папку «lib» Tomcat ($ CATALINA_HOME / lib), что и сделала наша команда.
Справедливое предупреждение о том, что, если вы используете этот подход, вы, скорее всего, будете располагать большинством своих JAR-файлов в общей папке lib, а не в отдельных веб-приложениях.Для нашего проекта это имело смысл, потому что большинство веб-приложений имеют общий доступ к одним и тем же внутренним службам.
Поскольку хардкорные разработчики Tomcat, скорее всего, будут возражать против размещения большого количества кода в каталоге общей библиотеки Tomcat, я просто перечислю некоторые причины, по которым другие предлагаемые ответы могут не работать.
- Использование отдельных контекстов приложения для каждой WAR будет означать наличие нескольких пулов соединений с базой данных, по одному для каждой WAR, и отдельную инициализацию дорогостоящего Hibernate SessionFactory для каждой WAR, что увеличивает время запуска сервера и потребление памяти.В более общем смысле, он не позволяет совместно использовать состояние общих серверных служб между веб-приложениями, работающими в том же Tomcat.
- Помещение персистентного кода в отдельную WAR и использование вызовов REST, по крайней мере, в нашем случае, совершенно неудобно для разработчиков и увеличивает длину пути к базе данных по сравнению с прямыми вызовами общих бинов.