Log4j для каждого класса, как определяется приоритет?

Question

Я пытаюсь разрешить ведение журнала отладки для определенного класса, используя Log4j, и у меня есть следующее:

log4j.rootLogger=stdout, daily

log4j.logger.com.mycompany.myapplication.mymodule=DEBUG

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{h:mm:ssa} %5p (%F:%L) - %m%n
log4j.appender.stdout.threshold=warn

log4j.appender.daily=org.apache.log4j.DailyRollingFileAppender
log4j.appender.daily.layout=org.apache.log4j.PatternLayout
log4j.appender.daily.layout.ConversionPattern=%d{h:mm:ssa} %5p (%F:%L) - %m%n
log4j.appender.daily.File=/some/file/path/stuff
log4j.appender.daily.DatePattern=MMdd'.log'
log4j.appender.daily.threshold=info

Если это файл WEB-INF / classes / log4j.properties как часть tomcat , должны ли отладочные сообщения из mycompany.myapplication.mymodule быть замечены или записи в файле позже переопределят его? (или я неправильно изменяю уровень ведения журнала для каждого класса?)

Во-вторых, , если файл log4j.properties включен в файл jar, мои настройки в Tomcat переопределяют эти?

Answer 1

Вы говорите своему классу, что нужно регистрироваться на уровне DEBUG, но просите, чтобы приложение игнорировало что-либо ниже WARN и INFO, чтобы вы не видели сообщений журнала.

Что касается порядка, в котором будет обнаружен log4j.properties:

1. WEB-INF / классы
2. Любой JAR в WEB-INF / lib
3. common / classes (в каталоге tomcat)
4. Любой JAR, который вы поместили в общий / одобренный
5. Любой JAR, который вы помещаете в общий / lib
6. общий / классы
7. Любой JAR, который вы помещаете в общий / lib

Обнаружение остановится с первым найденным файлом.

Answer 2

На ваш первый вопрос я бы сказал, что log4j.appender.daily.threshold=info - это проблема. Я не могу выбрать любое сообщение отладки.

Обычно мы не задаем порог для аппендера, уровни настраиваются для логгеров.

---

Я предлагаю вам использовать log4j.xml вместо log4j.properties. В дополнение к полезной проверке, он добавляет некоторые интересные функции или значения по умолчанию. Я точно не помню, какие именно ...

Answer 3

1. Я думаю, что вы должны предоставить mymodule аппендеру, как в

   log4j.logger.com.mycompany.myapplication.mymodule = DEBUG, Daily log4j.additivity.com.mycompany.myapplication.mymodule = ложь

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

2. Корень jar обычно не включается в CLASSPATH, поэтому свойства log4j.property внутри jar должны быть невидимы для JVM.

Answer 4

Да, похоже, вы правильно настраиваете свои индивидуальные регистраторы.

Нет, они не будут видны, потому что вы объявляете пороги на обоих ваших дополнениях, которые выше DEBUG:

log4j.appender.stdout.threshold=warn
log4j.appender.daily.threshold=info

Что касается «Во-вторых, если файл log4j.properties включен в файл jar, мои настройки в Tomcat переопределяют их?», Я не уверен, что вы подразумеваете под этим. log4j пытается загрузить log4j.xml или log4j.properties из пути к классам и будет использовать все, что найдет первым. IIRC, записи в общей папке lib Tomcat заменяют путь к классам каждого приложения. Если у вас есть конфигурация log4j в jar-файле в WEB-INF / lib и в текстовом файле в WEB-INF / classes, то вы по сути подбрасываете монету во время выполнения относительно того, какой из них будет использоваться.