Переупаковка нескольких WAR в один EAR - PullRequest
1 голос
/ 22 февраля 2010

Я работаю над проектом, в котором есть несколько веб-приложений (WAR), созданных с помощью Maven и развернутых в Java EE.

Эти WAR-файлы имеют несколько общих бизнес-JARS (например, один, содержащий объекты домена, которые загружаются из Hibernate) и другие JAR-файлы инфраструктуры, такие как Spring и Hibernate.

Они используют Spring MVC, а контекст приложения загружает Hibernate. Поскольку каждая WAR имеет свой собственный Classpath в контейнере сервлета, кэш Hibernate (EHcache) не используется совместно.

Что мне хотелось бы, так это разделить кеш, а также фабричный компонент сеанса гибернации (как и другие распространенные компоненты) между различными WAR-объектами. Я думаю, что это возможно, если переупаковать эти WAR-файлы в EAR, а затем мне нужно будет создать XML-конфигурацию Spring с использованием этих общих компонентов, а в Spring-файле WAR использовать что-то вроде SingletonBeanFactoryLocator из того, что я прочитал.

Я спрашиваю, есть ли простой способ сделать это, сводя к минимуму изменения в POM'ах WARs

Примечание: я знаком с WAR, tomcat и servlets, но не так много с EAR.

Заранее спасибо.

Ответы [ 3 ]

0 голосов
/ 26 января 2011

Рассматривали ли вы использование когерентного кластерного кэша L2? Если вы используете несколько серверов приложений, вы можете получить больше преимуществ, чем если бы они все использовали один и тот же связный кэш

0 голосов
/ 30 августа 2013

Использование общего родительского контекста приложения в приложении Multi-War Spring

http://blog.springsource.org/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/

0 голосов
/ 22 февраля 2010

Хммм ... Большинство контейнеров Java EE используют изолированные загрузчики классов для WAR, даже в EAR (даже если спецификация Java EE не требует изоляции загрузки классов между модулями одного EAR), поэтому я бы не стал не ожидайте многого от упаковки EAR, особенно если вы хотите, чтобы ваше приложение оставалось переносимым (т. е. если вы не хотите полагаться на какое-либо специфическое поведение сервера приложений).

Теперь, если действительно имеет смысл разделить вашу фабрику сессий и ваш кэш 2-го уровня между несколькими приложениями, возможно, стоит рассмотреть возможность объединения их в одну WAR. Это был бы самый простой способ ИМО. Но я хотел бы спросить , почему они отделяются тогда? Когда приложения разделены, они в большинстве случаев имеют отдельное управление, и я не знаю, будет ли их совместное развертывание хорошей идеей в таком случае.

И если объединение WAR не является возможным, скажите, пожалуйста, какой контейнер вы используете.

...