getResourceAsStream не загружает ресурс в веб-приложение

Question

У меня есть веб-приложение, которое использует библиотеку, которая находится в TOMCAT_HOME / common / lib. Эта библиотека ищет файл свойств в корне пути к классам (в классе ApplicationConfig):

ApplicationConfig.class.getResourceAsStream("/hv-application.properties");

Мое веб-приложение Tomcat содержит этот файл свойств. Именно в WEB-INF / classes, который является корнем правильного пути к классам? Однако во время выполнения, когда он пытается загрузить файл свойств, он генерирует исключение, потому что он не может его найти (getResourceAsStream возвращает null).

Все работает нормально, если мое приложение является простым, автономным приложением Java. Tomcat заставляет метод getResourceAsStream действовать по-другому? Я знаю, что есть много подобных вопросов, но, к сожалению, ни один из них не помог. Спасибо.

Answer 1

Попробуйте Thread.currentThread().getContextClassLoader().getResourceAsStream("/hv-application.properties") вместо.

Answer 2

Похоже, это может быть связано с работой загрузчиков классов Tomcat. Если у вас есть что-то в одном загрузчике классов (ваш файл конфигурации в загрузчике классов webapp), которое используется чем-то в другом (jar в common / lib), результатом может быть большая головная боль.

Этот документ объясняет, как Tomcat делегирует загрузчикам классов. Если возможно, вы можете попробовать одно из следующих:

1. Переместите файл jar с именем common / lib в ваше веб-приложение (WEB-INF / lib). Я знаю, что это не всегда возможно, но иногда jar-файлы (например, log4j) могут мирно сосуществовать с загрузчиками классов (*).
2. Переместите файл конфигурации в общие / классы. Это фактически то же самое (помещает элемент конфигурации в тот же загрузчик классов, что и jar, в котором он нуждается). Опять же, это не идеально, но если у вас есть контроль над вашей средой, это будет работать.

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

(*) log4j имеет опцию -log4j.ignoreTCL, которая делает это возможным, хотя

Answer 3

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

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

Answer 4

Я расширяю Комментарий Оливье в качестве ответа (спасибо за инициативу).

Кажется, проблема в начале косой черты (/) в пути к ресурсу.

В Tomcat 8 WebAppClassloader правильно разрешает путь с косой чертой и без нее.И .getResourceAsStream("/org/pakopa/app/config.properties");, и .getResourceAsStream("org/pakopa/app/config.properties"); возвращают InputStream.

В Tomcat 7 (И я предполагаю, что и предыдущие версии) .getResourceAsStream("/org/pakopa/app/config.properties"); не разрешается и возвращает null, но .getResourceAsStream("org/pakopa/app/config.properties");правильно решен.