Как настроить / создать собственный путь к классам, общий для немногих из многих веб-приложений в Jetty

Question

У нас есть несколько веб-приложений, упакованных как war и развернутых в jetty.base сервера jetty. Мы используем 9.4.26.v20200117 версию Jetty. Допустим, a.war, b.war, c.war and d.war. Они сгруппированы в два. Group 1 -> a.war and b.war и Group 2 -> c.war and d.war. У нас есть внешние jar-файлы зависимостей в jetty.base/lib/ext и jetty.base/lib/group2. В нашей организации только веб-приложения группы 1 принадлежат моей команде, а группа 2 принадлежит другой команде,

У нас включено -module-ext, и поэтому внешние библиотеки в jetty.base/lib/ext загружаются в classpath сервера и extraClassPath конфигурация используется в контексте xml (c. xml и d. xml) для веб-приложений группы 2 для загрузки внешних библиотек из jetty.base/lib/group2.

Проблема заключается в том, что при обновлении внешними jar-файлами из jetty.base/lib/ext до последней версии это влияет на веб-приложения группы 2, поскольку jetty.base/lib/ext загружается в системный путь к классам и отображается для всех веб-приложений. Было решено разорвать эту связь между группами. Мы (Группа 1) не смогли использовать конфигурацию extraClassPath, так как у нас есть один и тот же экземпляр, который будет использоваться всеми веб-приложениями группы 1. Один из возможных способов - создать каталог в jetty.base/lib (скажем, jetty.base/lib/group1) и переместить внешние jar из jetty.base/lib/ext в jetty.base/lib/group1, создать собственный путь к классам и загрузить в него внешние jar из jetty.base/lib/group1 и настроить его Пользовательский путь к классам доступен только для веб-приложений группы 1. Будем благодарны за любые предложения о том, как добиться этого или любых других возможных решений.

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

Answer 1

«общие зависимости между веб-приложениями» - одна из причин, по которой существует JNDI.

- «уменьшить размер военного пакета» - ложная причина (Jetty была протестирована до 4 ГБ военных файлов, с около 5000 jars в WEB-INF / lib с объединением более 2 000 000 миллионов записей)

Вариант 1. Правильное использование файлов WAR, устранение общих зависимостей.

Если вы пропустить общие общие зависимости, которые вы ...

• Улучшить время запуска сервера.
• Улучшить время развертывания веб-приложения.
• Разрешить горячее развертывание для работы (вы не включаете блокировку / закрепление загрузчиков классов)
• Уменьшено использование памяти (при использовании традиционных файлов war без общих ресурсов используются дескрипторы файлов LESS)
• Файловая система I / O уменьшается (файл блокируется / contention / et c для ресурсов общего JAR, доступ к которым осуществляется из нескольких загрузчиков классов)

Вариант 2. Правильное использование JNDI.

Если вы все еще н Используйте общие ресурсы (заметьте, я сказал «ресурсы», а не зависимости, не загрузчики классов и т. д. c), затем рассмотрите возможность настройки ресурсов через API и совместного использования этого ресурса с JNDI.

Вы должны связать ресурс в расположение JNDI по вашему выбору на уровне сервера, предоставляя только API в качестве метода использования.

Поместите jar-файлы API (не jar-файлы реализации) в ваши war-файлы WEB-INF/lib каждого веб-приложения.

Запустите веб-приложение, получите доступ к общему ресурсу через поиск JNDI, используйте этот ресурс через API.

Это разделит ресурс и то, как различные загрузчики классов работают правильно.

Загрузчик классов сервера отвечает за общий ресурс.

Каждый загрузчик классов веб-приложения отвечает за свой собственный jar API, обращаясь к общему ресурсу через слой JNDI.

Опция 3: удаление вся изоляция загрузчика классов WebApp и инвертирование поведения.

Этот параметр вряд ли будет хорошим выбором Если вы хотите описать проблему, просто включите ее здесь для полноты.

В вашем WebAppContext вы можете щелкнуть кнопкой мыши на том, как поведение поиска загрузчика классов работает полностью. От пути сервлета c к пути Java спецификатора c.

Используйте WebAppContext.setParentLoaderPriority(true), чтобы использовать поведение Java.

Это означает, что когда вашему веб-приложению нужен класс, он сначала проверяет родительский загрузчик классов (сервер), а затем веб-приложение для загрузки класса.