Управление путем к классу в сервлете
- Убедитесь, что у вас нет других ошибок или предупреждений.
- Попробуйте удалить имя обработчика события в вашем HTML и сгенерировать его снова, используя Visual Studio. Затем проверьте, присутствует ли он в том же файле с выделенным кодом, который вы просматривали ранее.
6 ответов
Насколько я понимаю, что выбор ресурса от пути к классу недетерминирован (с точки зрения разработчика приложения). Даже если тот же файл последовательно загружается, поведение могло бы измениться: 1. При обновлении версии текущего контейнера. 2. При переключении контейнеров.
Простое решение будет состоять в том, чтобы удалить встроенные log4j файлы конфигурации из банок библиотеки. Это почти никогда не хорошая идея встроить log4j конфигурацию, когда это приводит к проблеме, которую Вы видите здесь...
Они - сторонние банки или банки, которые Вы разработали?
Tomcat 8.5
Так же Tomcat 8.0.
См. документацию: ПРАКТИЧЕСКОЕ РУКОВОДСТВО Загрузчика Класса.
Tomcat 8.0
Ответ прост, взят от страницы документации Tomcat, ПРАКТИЧЕСКОГО РУКОВОДСТВА Загрузчика Класса. В особенности заметьте использование /WEB-INF/ каталог/папка.
Поэтому с точки зрения веб-приложения, класса или загрузки ресурса смотрит в следующих репозиториях, в этом порядке:
- Классы начальной загрузки Вашей JVM
/WEB-INF/classesиз Вашего веб-приложения/WEB-INF/lib/*.jarиз Вашего веб-приложения- Системные классы загрузчика класса (описанный выше)
- Общие классы загрузчика класса (описанный выше)
Если загрузчик класса веб-приложения настроен с
<Loader delegate="true"/>затем порядок становится:
- Классы начальной загрузки Вашей JVM
- Системные классы загрузчика класса (описанный выше)
- Общие классы загрузчика класса (описанный выше)
/WEB-INF/classesиз Вашего веб-приложения/WEB-INF/lib/*.jarиз Вашего веб-приложения
Tomcat 6
Извлеченный из Tomcat 6 страниц, ПРАКТИЧЕСКОГО РУКОВОДСТВА Загрузчика Класса.
Поэтому с точки зрения веб-приложения, класса или загрузки ресурса смотрит в следующих репозиториях, в этом порядке:
- Классы начальной загрузки Вашей JVM
- Системные классы загрузчика класса (описанный выше)
/WEB-INF/classesиз Вашего веб-приложения/WEB-INF/lib/*.jarиз Вашего веб-приложения$CATALINA_HOME/lib$CATALINA_HOME/lib/*.jar
Мы Spring Log4jConfigListener в нашем файле web.xml.
Можно указать как параметр контекста местоположение log4j файла конфигурации, т.е. Вы могли установить его как /WEB-INF/log4j.xml
Это было бы опцией для Вас? Если Вы не используете Spring, я знаю, что можно установить местоположение Log4j программно, которое могло бы также работать.
По моему опыту, WEB-INF/classes обычно имеет приоритет по банкам в WEB-INF/lib, однако, который также зависит от контейнера сервлета, который Вы используете (я никогда не мог выяснять поведение JRun, например). Помогло бы очень, если Вы могли бы сказать мне, какой контейнер Вы используете.
Кроме того, действительно ли Вы уверены, что оскорбление log4j конфигурация находится в банке в WEB-INF/lib? Как правило, когда я столкнулся с проблемами пути к классу в ситуации с контейнером сервлета, это из-за библиотек, которые находятся за пределами веб-приложения.
Спецификации сервлета рекомендуют, чтобы веб-приложение classloaders загрузило их собственные классы прежде, чем делегировать к classloader контейнера (SRV.9.7.2), но так как это в противоречии со спецификацией Java, не, все поставщики делают это по умолчанию (на самом деле, Tomcat является единственным контейнером, который я использовал, который делает это по умолчанию). После этих слов всегда возможно настроить веб-приложение Вашего контейнера classloading поведение. Если Вы говорите мне, какой контейнер Вы используете, я могу помогать Вам (а именно, я сделал это успешно прежде на WebLogic, WebSphere, Glassfish и JRun)).
У Вас должен быть log4j.properties в Вашем ПУТИ К КЛАССУ. Лучшее место находится под WEB-INF/classes.
Также необходимо удостовериться, что Вы используете свою версию log4j.jar. Так, поместите его в WEB-INF/lib, только чтобы удостовериться, что Вы не используете один от папок кота, так как это может вызвать странные проблемы classloading.
Если Вы не можете управлять путем к классу, так как Tomcat устанавливает его для Вас, Вы, по крайней мере, способный установить системное свойство для log4j.configuration? Я полагаю, что местоположение, на которое указывает то свойство, может быть установлено за пределами пути к классу.
В противном случае другой подход, хотя ужасный, должен был бы явно выполнить один из конфигураторов самостоятельно в Вашем коде приложения.