Родительское веб-приложение Tomcat, доступное для настраиваемых дочерних веб-приложений

Question

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

Мы хотели бы иметь родительское веб-приложение, которое будет доступно всем дочерним веб-приложениям. Затем пусть каждое дочернее веб-приложение переносит только файлы, относящиеся к ним. Когда дочернее веб-приложение запускается, Tomcat загружает веб-приложение из родительского веб-приложения и затем переопределяет любые файлы, определенные в дочернем веб-приложении, следуя идентичной структуре пакета.

Мы гуглили и не нашли готового или полного решения. Решения, на которые мы смотрели:

1. Tomcat common / share - может обрабатывать файлы классов и JAR, но мы не видим способа обработки статических ресурсов и ресурсов JSP, находящихся над каталогом WEB-INF.
2. CATALINA_BASE, похоже, больше подходит для запуска нескольких экземпляров Tomcat, которых мы бы лучше избегали
3. Возможное решение для Maven, но мы не большие поклонники Maven, поэтому лучше его тоже избегать.

У кого-нибудь есть предложения или идеи, как это решить? Если конфигурация Tomcat невозможна, как насчет другого сервера приложений (такого как Glassfish) или инструмента для обновления динамического файла (такого как OSGi, rsync). Хотел бы по возможности удалить дублирование ресурсов.

Спасибо.

Answer 1

Не существует таких понятий, как «родительские» или «дочерние» веб-приложения. Он не является частью спецификации J2EE и AFAIK, он не поддерживается ни одним сервером приложений.

Тем не менее, ваша проблема двоякая:

1) Имея общие ресурсы. Эта часть довольно проста, если предположить, что «ресурсы» означают статические ресурсы (images / CSS / javascript / etc ...).

• Если они действительно являются общими (например, вам не нужна отдельная версия в некоторых из ваших веб-приложений), разместите их в другом месте (отдельное «общее» веб-приложение или поставьте Apache перед вашим Tomcat и разместите их там.
• Если вам нужно необходимо иметь "локальные" версии некоторых из этих ресурсов, вы можете сделать несколько умных условных перезаписей URL или просто написать сервлет, который проверял бы, конкретный ресурс существует локально и, если нет, возьмите его из «общего» местоположения.
• Предварительно скомпилируйте ваши JSP, чтобы вам приходилось иметь дело только с JAR.
• Если ваш экземпляр Tomcat содержит только ваши приложения, вы действительно можете поместить свои JAR-файлы в shared (или lib в последней версии); в противном случае вы можете развернуть их с каждым приложением.

2) Упрощение развертывания. Я не совсем уверен, в чем здесь большая проблема ... Довольно просто написать сценарий Ant (пакетный режим, что у вас есть), который бы собирал и развертывал WAR на основе «общего» и структуры каталогов для приложения.

В качестве альтернативы вы можете захотеть взглянуть на использование JNDI для значительного сокращения количества файлов, которые необходимо развернуть (теоретически, до одного context.xml для каждого приложения).

Answer 2

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

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

Однако это не решит вашу проблему, если вы хотите переопределить логику.

Вариант, который я изучаю для аналогичного сценария, - это перемещение пользовательской части клиента в виджеты / гаджеты ajax. Затем включите его в файлы конфигурации, чтобы сообщить приложению, какую версию гаджета использовать для какого клиента.

вы можете ознакомиться с документацией о том, как приложения делятся базой документов, здесь http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

Answer 3

Вы можете построить иерархию «родитель-потомок», если используете Spring в своих веб-приложениях - Использование общего родительского контекста приложения в мультивоенном приложении Spring .

т.е. вы можете определить все совместно используемые вещи в контексте 'parent' и иметь контексты 'child' только для его использования.