Лучшие практики сторонних библиотек в Tomcat

Question

Я использую Tomcat для размещения своих приложений Java Web и веб-сервисов в течение длительного времени. В основном для приложений Spring и Grails на данный момент.

В последнее время в одном проекте возникла дискуссия о том, как работать с зависимостями / библиотеками в производственных средах Tomcat:

В моих проектах я развертываю большие WAR-файлы , хранящие все необходимые зависимости для приложения в папке WEB-INF / lib. Единственные вещи, которые я помещаю в папку tomcat / lib, - это файлы JAR для соединений JDBC, управляемых tomcat.

Клиент имеет давнюю историю с WebSphere и считает, что контейнер должен содержать большинство необходимых зависимостей. Поэтому они хотят поместить JAR-файлы для используемых платформ или API-интерфейсы WebService (например, Metro) в папку tomcat / lib и иметь тощие WAR-файлы .

Проблема с этим решением, на мой взгляд, заключается в том, что если у вас есть приложение, для которого требуется другая версия зависимости, которая уже включена в папку tomcat / lib, вы можете получить ошибки и странное поведение.

Есть ли лучшие практики или официальный документ, в котором говорится об этой проблеме? Что вы думаете об этом?

Answer 1

Упаковка зависимых фляг в файл войны может дать больший файл войны, но это дает много преимуществ. Большой военный файл становится единым, автономным, полным подразделением развертывания. Вы можете взять этот файл war и развернуть его на рабочем столе разработчика, в среде принятия клиентов и производственной среде и быть уверенным, что ваш собственный код в файле war ссылается на ожидаемые версии всех зависимостей.

По моему опыту, единственный раз поместить jar в папку lib Tomcat вместо файла war - это когда ваш код ссылается на некоторую библиотеку за интерфейсом, и вы не узнаете базовую реализацию до времени развертывания. Например, у меня был проект, интегрирующийся с JMS, и я знал, что должен поддерживать несколько развертываний инфраструктуры обмена сообщениями. В некоторых средах необходимо использовать ActiveMQ. Другие среды, необходимые для использования Websphere MQ. В этом случае я упаковал jar-интерфейс JMS в файл war, а затем во время развертывания поместил jar-файл ActiveMQ или Websphere MQ в tomcat / lib.

Конечно, это означало, что файл войны уже не был полноценной единицей развертывания. Вместо этого развертывание было двухэтапным процессом. Это компромисс. Я подумал, что это проще, чем управлять несколькими вариантами сборки военных файлов, каждый из которых объединяет свой JAR-провайдер.

Answer 2

Есть ли какой-либо передовой опыт или официальный документ, в котором говорится об этой проблеме?

Я сомневаюсь, что вы найдете официальные документы (от разработчиков / сообщества Tomcat) в поддержку этой теории, хотя она очень верна. Мне пришлось подготовить один в моей предыдущей работе, чтобы файл EAR приложения мог быть развернут в нескольких контейнерах J2EE.

Хотя есть одна вещь в пользу. Вы можете вызвать IBM Redbook под названием "WebSphere Application Server V6.1: определение проблемы загрузчика классов" (довольно устарело, учитывая, что доступен WAS 7), в котором показано, как создавать общие библиотеки в WebSphere. В WebSphere можно создать несколько таких библиотек для приложений, для которых требуются разные версии. В Tomcat вы являетесь администратором, который может не знать, что такое загрузчик классов, учитывая, что все разделяемые библиотеки выгружаются в $ CATALINA_HOME \ lib .

В Redbook также есть несколько советов (замените файл утилиты утилитой JAR, и вы получите свой ответ):

Где вы не должны размещать служебные файлы

Решая, где лучше разместить служебные файлы, важно признать, что эти файлы не должны быть включенным в WebSphere Среда сервера приложений.

Например: app_server_root / lib, app_server_root / lib, / ext *, app_server_root / java (включая любой подкаталоги) или путь к классу JVM.

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

Answer 3

Я бы пошел на дополнительные пакеты: http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/index.html

Шаги:

1. Упакуйте свой код, библиотеки в jar / war.

2. В MANIFEST.MF из вышеприведенного объявить список расширений jar

3. Направить их в целевые приложения