разные WAR-файлы, общие ресурсы

Question

Предположим, у вас есть несколько приложений, которые используют один и тот же код и большинство других ресурсов, но выглядят несколько иначе, некоторые ярлыки меняются и т. Д. (Например, брендинг). Если каждое веб-приложение должно идти в своем собственном файле WAR, куда вы помещаете общие ресурсы?

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

Я также подумал о скрипте сборки, который выполняет магию и из общего источника извергает (немного) разные WAR, но мне это не нравится, потому что он просто усложняет вещи, когда вам нужно собрать / протестировать / запустить одно приложение.

Любые другие советы и рекомендации будут оценены.

Answer 1

Стратегия, которую я видел для такой линейки продуктов, как конфигурации, использует WAR оверлеи при сборке с maven . Вы определяете общий WAR, который содержит общий материал, и накладываете его на другие WAR, которые содержат определенный материал, чтобы генерировать различные WAR для каждого приложения. Этот метод, вероятно, наиболее полезен, если вы развертываете WAR-варианты на разных машинах. Но я не уверен, могу ли я действительно рекомендовать это.

Не забудьте указать конфигурацию оверлеев, если вы на самом деле переопределяете материал, поскольку в противном случае порядок переопределения не является детерминированным. Это может даже измениться с обновлением maven-war-plugin. (Это было в нашем случае.)

Answer 2

Вы можете развернуть оба WAR в одном EAR и поместить общие ресурсы в EAR. Затем поместите соответствующие зависимости в манифест веб-приложений для ссылки на файлы jar в ухе.

Answer 3

Если вы не хотите идти по EAR-маршруту, используя tomcat и т.д .; Есть несколько других способов достижения желаемой последовательности.

Если вы хотите поделиться только js и css, посмотрите на pack: tag . Вы можете разместить .js и css на сервере apache, настроить свой httpd.conf, чтобы ваши веб-приложения могли вызывать его, а затем использовать pack: tag из войн приложений - DRY и сжатие за один шаг.

Answer 4

Как насчет того, чтобы поместить ваши css и js в путь к классам и обслужить их сервлетом? Затем вы можете собрать общие ресурсы как jar, и этот jar может даже содержать сервлет (диспетчер ресурсов, если хотите), а файлы war могут содержать файл jar в папке WEB-INF / lib.

Answer 5

Обновление

Да, я снова. Я действительно передумал (снова :)). В настоящее время я пытаюсь (быть более осторожным здесь):

• (Common) WAR: содержит приложение, common (большая часть) + некоторые специфические вещи
• EAR1: CommonWAR + специальный файл конфигурации для env1
• EAR2: CommonWAR + специальный файл конфигурации для env2

Файл конфигурации выбирается WAR. Он находится в пути к классу EAR и содержит только одно свойство 'application' со значением. Единственная WAR затем будет использовать эту информацию, где необходимо, чтобы различать два приложения (config, таблицы стилей, ...).

С моим решением EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2 было слишком сложно или невозможно искать статические ресурсы в CommonWAR без использования веб-URL (например, изображения в документах PDF, созданные с помощью iText).

Answer 6

Спасибо за ответы до сих пор, но я боюсь, что забыл упомянуть, что WAR-файлы будут развернуты в разных средах, которые полностью изолированы друг от друга.

Так что, возможно, единственная опция, развернутая рядом с действующим приложением, - это общая WAR. Я думаю, я пойду со следующим:

• WAR1, WAR2, содержащий материал для приложения
• CommonWAR, связывающий обычные вещи (без шуток)
• EAR1: WAR1 + CommonWAR, для развертывания в env1
• EAR2: WAR2 + CommonWAR, для развертывания в env2