2008-11-05 2 views
6

Приложение моего сервлета включает в себя несколько библиотек .jars, некоторые из которых содержат встроенные файлы log4j.xml или log4j.properties. Я хочу, чтобы log4j сначала нашел мой log4j.xml! Я попытался найти некоторую спецификацию приоритетов различных элементов classpath в сервлете (например, WEB-INF/классы всегда предшествуют WEB-INF/lib?) Или каким-то образом настраивать или настраивать загрузчик классов сервлета, чтобы данный каталог ресурсов появляется на ранней стадии пути к классам. Пока что я нарисовал пробел. Любые предложения по обеспечению того, что файл сервлета .war загружает правильный файл log4j.xml через загрузчик классов?Управление путём классов в сервлете

ответ

4

Насколько я понимаю, выбор ресурсов из пути к классам является недетерминированным (с точки зрения разработчика приложения). Даже если один и тот же файл будет загружен последовательно, поведение может измениться: 1. При обновлении версии текущего контейнера. 2. Если вы переключаете контейнеры.

Простым решением будет удалить встроенные файлы конфигурации log4j из библиотеки jars. Практически никогда не рекомендуется вставлять конфигурацию log4j, так как это приводит к проблеме, которую вы видите здесь ...

Являются ли они сторонними банками или банками, которые вы разработали?

+0

Третья сторона, отсюда и проблема. – 2008-11-05 11:03:36

+0

С риском безжалостного звучания, вы должны назвать и позорить их в вопросе, а также подать ошибку тоже ... – johnstok 2008-11-05 12:44:38

-1

В вашем CLASSPATH необходимо иметь log4j.properties. Лучшее место в разделе WEB-INF/classes.

Вы также должны убедиться, что используете свою версию log4j.jar. Итак, поместите его в WEB-INF/lib, чтобы убедиться, что вы не используете его в папках tomcat, так как это может вызвать проблемы с загрузкой.

+0

Это на самом деле не ответить на вопрос, который я задал. Является ли WEB-INF/классы гарантированными на пути к классам до WEB-INF/lib? Что делать, если я хочу, чтобы мой log4j.xml не был в WEB-INF/классах, но другой каталог - это не класс в конце концов. – 2008-11-05 11:02:02

+0

Но это должно быть в пути к классам – Marko 2008-11-05 11:04:47

3

Мы весна Log4jConfigListener в нашем файле web.xml.

Вы можете указать в качестве параметра контекста расположение файла конфигурации log4j, то есть вы можете установить его в качестве /WEB-INF/log4j.xml

Будет ли это вариант для вас? Если вы не используете Spring, я знаю, что вы можете установить местоположение Log4j программно, что также может работать.

1

В моем опыте, например, WEB-INF/классы имеют приоритет над jars в WEB-INF/lib, что также зависит от используемого вами контейнера сервлета (я никогда не мог понять поведение JRun, например) , Это очень помогло бы, если бы вы могли сказать мне, какой контейнер вы используете.

Кроме того, вы уверены, что оскорбительная конфигурация log4j находится в банке в WEB-INF/lib? Как правило, когда я столкнулся с проблемами классов в контексте контейнера сервлетов, это из-за библиотек, которые находятся в за пределами веб-приложения.

Сервлет спецификация ВЫГОДНО, что веб-приложение загрузчики классов загружать свои собственные классы до передачи в загрузчик классы контейнера (SRV.9.7.2), но так как это противоречит спецификации Java, не все производители делают это по умолчанию (на самом деле Tomcat - единственный контейнер, который я использовал, который делает это по умолчанию). С учетом сказанного, всегда можно настроить поведение загрузки класса веб-приложения вашего контейнера. Если вы скажете мне, какой контейнер вы используете, я могу помочь вам (в частности, я сделал это успешно ранее в WebLogic, WebSphere, Glassfish и JRun)).

1

Если вы не можете контролировать путь к классам, так как Tomcat настраивает его для вас, вы, по крайней мере, можете установить системное свойство для log4j.configuration? Я считаю, что местоположение, на которое указывает это свойство, может быть установлено за пределами пути к классам.

Если нет, другой подход, хотя и уродливый, должен был явно запустить один из конфигураторов самостоятельно в вашем коде приложения.

15

Tomcat 8.5

Ditto Tomcat 8.0.

См. Документацию: Class Loader HOW-TO.

Tomcat 8.0

Ответ прост, взятый со страницы документации Tomcat, Class Loader HOW-TO. В частности, обратите внимание на использование каталога/папки /WEB-INF/.

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

  • Загрузочные классы вашей виртуальной машины Java
  • /WEB-INF/classes вашего веб-приложения
  • /WEB-INF/lib/*.jar вашего веб-приложения
  • Классы классов классов системы (описанные выше)
  • классов общих загрузчика классов (описанные выше)

Если загрузчик классов веб-приложение configured с <Loader delegate="true"/> то порядком становится:

  • Загрузочных классов вашего виртуальной машины Java
  • класса системного загрузчика классов (описанным выше)
  • Классы классов классов классов (описанные выше)
  • /WEB-INF/classes вашего веб-приложения
  • /WEB-INF/lib/*.jar вашего веб-приложения

Tomcat 6

Выдержки из Tomcat 6, стр Class Loader HOW-TO.

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

  • Загрузочные классы вашей виртуальной машины Java
  • класс системный загрузчик классов (описанного выше)
  • /WEB-INF/classes вашего веб-приложения
  • /WEB-INF/lib/*.jar вашего веб-приложения
  • $CATALINA_HOME/lib
  • $CATALINA_HOME/lib/*.jar
Смежные вопросы