Ваша основная проблема заключается в том, чтобы сосредоточиться вокруг физических, статических активов системы, а все остальное - просто, эффективно, баночки.
WAR в Tomcat разделены отдельными загрузчиками классов, но также они разделены на уровне сеанса (каждый WAR является отдельным веб-приложением и имеет свое собственное состояние сеанса).
В Glassfish, если WAR-файлы были объединены в EAR, они бы совместно использовали загрузчики классов (GF использует пространство загрузчика плоских классов в EAR), но все равно имели бы отдельное состояние сеанса.
Кроме того, я не уверен, что вы можете выполнить «пересылку» на другую WAR на сервере. Проблема заключается в том, что пересылки используют относительный URL-адрес к корню веб-приложения, и у каждого веб-приложения есть свой собственный корень, поэтому вы просто «не можете добраться отсюда». Вы можете перенаправить, но это не то же самое, что форвард.
Таким образом, эти функции веб-приложения сговорились против того, чтобы вы пытались равномерно развернуть их в контейнере.
Скорее, я думаю, что горячим советом является создание утилиты «ассемблер», которая берет ваши отдельные модули и «объединяет» их в одно веб-приложение. Он может объединять их web.xml, их содержимое, нормализовать jar-файлы и классы и т. Д.
WAR - это особенность и ошибка в мире Java. Я люблю их, потому что они действительно делают развертывание скомпилированных приложений «перетаскиванием» с точки зрения их установки, и эта функция используется гораздо больше, чем то, с чем вы сталкиваетесь. Но я чувствую твою боль. У нас есть общая «базовая» структура, которую мы разделяем между приложениями, и нам в основном приходится постоянно объединять ее, чтобы поддерживать ее. Мы написали это, но это все еще немного болезненно.