getResourceAsStream, не загружающий ресурс в веб-приложении
У меня есть веб-приложение, которое пользуется библиотекой, которая находится в TOMCAT_HOME/common/lib. Эта библиотека ищет файл свойств в корне пути к классу (в классе под названием ApplicationConfig):
ApplicationConfig.class.getResourceAsStream("/hv-application.properties");
Мое веб-приложение Tomcat содержит этот файл свойств. Это находится в WEB-INF/classes, который является корнем права пути к классу? Однако во времени выполнения, когда это пытается загрузить файл свойств, это выдает исключение, потому что это не может найти его (getResourceAsStream, возвращает пустой указатель).
Все хорошо работает, если моим приложением является простое, автономное JAVA-приложение. Tomcat заставляет getResourceAsStream метод действовать по-другому? Я знаю, что существует много подобных вопросов там, но ни один из них не помог, к сожалению.Спасибо.
3 ответа
Попробуйте вместо этого Thread.currentThread (). GetContextClassLoader (). GetResourceAsStream ("/ hv-application.properties") .
Похоже, это может быть связано с тем, как работают загрузчики классов Tomcat. Если у вас есть что-то в одном загрузчике классов (ваш файл конфигурации в загрузчике классов webapp), которое используется чем-то в другом (jar в common / lib), результатом может стать большая головная боль.
Этот документ объясняет, как Tomcat делегирует полномочия загрузчикам классов. Если возможно, не могли бы вы попробовать одно из следующего:
- Переместите файл jar в common / lib в ваше веб-приложение (WEB-INF / lib). Я знаю, что это не всегда возможно, но иногда банки (например, log4j) могут мирно сосуществовать между загрузчиками классов (*).
- Переместите ваш файл конфигурации в common / classes. По сути, это то же самое (помещает элемент конфигурации в тот же загрузчик классов, что и jar, который в нем нуждается). Опять же, это не идеально, но если у вас есть контроль над окружающей средой, это сработает.
В любом случае наличие ресурсов в разных загрузчиках классов может быть проблемой. Надеюсь, это поможет.
(*) log4j имеет параметр -log4j.ignoreTCL , который делает это возможным, хотя
Менеджер безопасности Tomcat обычно не позволяет вам получить доступ к классам и ресурсам webapp из библиотек в корне Tomcat библиотеки. Это предназначено для разделения веб-приложений, работающих в контейнере.
Вы сможете обойти это, обновив политику безопасности, но, как правило, лучше не помещать ваши библиотеки в контейнер Tomcat, что, как я полагаю, вы делаете.