Конфликтующие JAR-файлы: не должен ли WEB-INF / lib иметь приоритет над всеми остальными местами? - PullRequest
Новая
       14

Конфликтующие JAR-файлы: не должен ли WEB-INF / lib иметь приоритет над всеми остальными местами?

3 голосов
/ 25 февраля 2012

Моя среда развертывания очень испорчена: jar-файлы разбросаны по всей системе, и я не могу это контролировать.Например, мое веб-приложение использует последнюю версию Javamail API, но, похоже, в $JAVA_HOME/jre/lib/ext имеется несколько копий одной и той же библиотеки (очевидно, все более старые и разные версии).То же самое относится и к драйверам поставщиков баз данных, не говоря уже о $CATALINA_HOME/lib. Я не могу ничего очистить , но, очевидно, мне нужно убедиться, что мое приложение получает минимально требуемую версию его зависимостей, поэтому я поместил все необходимые JAR-файлы в WEB-INF/lib.Согласно спецификации сервлета и Tomcat docs :

Когда обрабатывается запрос на загрузку класса из загрузчика классов WebappX веб-приложения, этот загрузчик классов сначала просматривает локальные репозитории.вместо того, чтобы делегировать, прежде чем искать

, так что это должно решить мою проблему.Но тогда тот же самый документ говорит:

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

  1. Классы начальной загрузки вашей JVM
  2. Классы загрузчика системных классов (описанные выше)
  3. / WEB-INF / классы вашего веб-приложения
  4. / WEB-INF / lib / *.jar вашего веб-приложения
  5. Общие классы загрузчиков классов (описанные выше)

А на самом деле классы в /WEB-INF/lib загружаются после системных,Это действительно ожидаемое поведение?Разве вы не находите, что документы Tomcat противоречивы?Знаете ли вы какой-нибудь контейнер сервлетов, который гарантирует, что я могу получить правильные зависимости?Как я могу решить эту проблему?

Ответы [ 2 ]

4 голосов
/ 26 февраля 2012

Укуси пулю и вычисти.

Любое решение, которое ты придумаешь, зависит от порядка загрузки классов, будет хрупким, запутанным и очень трудным для отладки.Например, если вы по какой-то причине забудете упаковать класс, вдруг вы подберете немного другую версию ... Я возьму хорошую чистую исключительную ситуацию ClassNotFoundException в случае совершенно произвольного поведения!

4 голосов
/ 25 февраля 2012

Если ext-папка заражена, вам в основном не повезло.

Единственное, что вы можете сделать, - это упаковать весь необходимый код, включая jar-файлы, в отдельную иерархию пакетов и упаковать сваше приложение.Это будет означать, что com.foo.Bar станет org.raffaele.com.foo.bar или подобным.Затем используйте только эти новые имена.

Остерегайтесь отражения и строк с именами классов, но это можно сделать.

Я не знаю, существует ли инструмент, который может полностью автоматизировать этот процесс.

...