Оптимальная практика сторонних библиотек в Tomcat

Я использую 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, вы можете получить ошибки и странное поведение.

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

Ответы

Ответ 1

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

Я сомневаюсь, что вы найдете официальные документы (от разработчиков/сообщества 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 классы, которые могут нанести ущерб общая функциональность сервера.

Ответ 2

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

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

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

Ответ 3

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

Шаги:

  • Пакет кода, библиотеки в банке/войне.

  • В MANIFEST.MF из вышеперечисленного объявите баннеры расширений

  • Ссылаются в целевые приложения