Как контролировать ведение журнала сторонними компонентами в веб-приложении в Tomcat 5.5? - PullRequest
Новая
       32

Как контролировать ведение журнала сторонними компонентами в веб-приложении в Tomcat 5.5?

2 голосов
/ 30 марта 2011

Мы используем Tomcat 5.5 в Linux.Наше веб-приложение использует log4j для своей регистрации (функционально на основе и не так много регистраторов) и намеренно устанавливает аддитивность регистраторов на false.Наши регистраторы регистрируются в нашем собственном лог-файле.Ни один из них не входит в консоль.

Проблема, с которой мы сталкиваемся, состоит в том, что, когда уровень наших регистраторов установлен на DEBUG, мы начинаем получать большое количество отладочных журналов в catalina.out от сторонних компонентов, в частности от oscache.

Существует минимальный файл log4j.properties в ... / common / classes: 

log4j.rootLogger=INFO, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# Print the date in ISO 8601 format
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

В файле ... / webapps / ourapp / WEB- нет файла log4g.propertiesINF / classes.

Первым, что я попробовал, было изменение на log4j.rootLogger=ERROR, A1, но это не имело никакого значения.

Следующим, что я попробовал, было создание ... / webapps / ourapp / WEBФайл -INF / classes / log4j.properties, содержащий одну строку 

log4j.logger.com.opensymphony.oscache=ERROR

, чтобы проверить, не остановит ли это запись в журнал oscache.Это произошло, но на удивление (для меня) это остановило все нежелательные журналы, а не только журналы oscache.Поэтому я прокомментировал строку и попробовал еще раз.По-прежнему никаких нежелательных записей в журнале.Я переместил файл в сторону, и теперь нежелательные записи вернулисьЯ создал файл log4j.properties нулевой длины, и все нежелательные журналы снова исчезли (!). Хотя это в краткосрочной перспективе то, что я хочу, это заставляет меня задуматься о том, какие другие журналы удаляются (и почему!).Поэтому мне неудобно просто полагаться на это.

В главе «Ведение журнала» в документах Tomcat 5.5 просто сказано, что вы можете выполнить настройку для каждого приложения, поместив файл свойств в WEB-INF / classes, но неt (по крайней мере, не то, что я мог найти) поговорим о том, как это взаимодействует с конфигурацией, указанной в common / classes.

Итак:

  • Как сторонние компоненты регистрируются вcatalina.out на первом месте?Я предполагаю, что их журналирование может пузыриться до корневого регистратора, но тогда почему они все еще регистрируются, даже когда уровень корневого регистратора повышен до ОШИБКИ?
  • Почему установка уровня регистратора на наших регистраторах на ОТЛАДКУ делает эту регистрациюНачните?У нас есть свои собственные имена для наших регистраторов, поэтому нет никакой возможности, чтобы oscache и другие вещи могли быть предками наших регистраторов.
  • Почему даже файл WEB-INF / classes / log4j.properties нулевой длины останавливает целую кучу журналирования?
  • Как я могу сделать это "правильным" способом и ограничить регистрациюосмысленно, а не полагаться на какой-то странный (для меня) побочный эффект, чтобы отключить его?

Любопытнее и страннее.Я попробовал предложение Мэтта включить отладку.Я также сделал более обширный файл log4j.properties для веб-приложения: 

log4j.rootLogger=INFO, SSOA1
log4j.appender.SSOA1=org.apache.log4j.ConsoleAppender
log4j.appender.SSOA1.layout=org.apache.log4j.PatternLayout

# Print the date in ISO 8601 format
log4j.appender.SSOA1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

log4j.logger.com.opensymphony.oscache=ERROR
#log4j.additivity.com.opensymphony.oscache=false

Когда tomcat запускается, я вижу: 

log4j: Using URL [file:/srv/www/tomcat5/base/webapps/myapp/WEB-INF/classes/log4j.properties] for automatic log4j configuration.
log4j: Reading configuration from URL file:/srv/www/tomcat5/base/webapps/myapp/WEB-INF/classes/log4j.properties
log4j: Parsing for [root] with value=[INFO, SSOA1].
log4j: Level token is [INFO].
log4j: Category root set to INFO
log4j: Parsing appender named "SSOA1".
log4j: Parsing layout options for "SSOA1".
log4j: Setting property [conversionPattern] to [%d [%t] %-5p %c - %m%n].
log4j: End of parsing for "SSOA1".
log4j: Parsed "SSOA1" options.
log4j: Parsing for [com.opensymphony.oscache] with value=[ERROR].
log4j: Level token is [ERROR].
log4j: Category com.opensymphony.oscache set to ERROR
log4j: Handling log4j.additivity.com.opensymphony.oscache=[null]
log4j: Finished configuring.

Но, несмотря на то, что у logache oscache свой уровеньустановлен на ошибку, я все еще вижу такие вещи в журнале: 

2011-03-30 14:53:22,076 [main] DEBUG com.opensymphony.oscache.base.algorithm.AbstractConcurrentReadCache - get called (key=AUDIT_KEY_OLDEST_TIMSTAMP)

Если я устанавливаю уровень регистратора oscache в ОШИБКУ (что выводится в отладочном отчете log4j), то почему это отладка?сообщение отправляется вообще?Дочерний регистратор, переопределяющий уровень в коде?

Что я заметил, так это то, что если я раскомментирую строку «addidity» для регистратора oscache в файле log4j.properties веб-приложения, тогда регистрация действительно исчезнет.Таким образом, создается впечатление, что регистрация в oscache основана на дополнениях предка, а не на его собственных.Но тогда, кажется, все более странно, что установка уровня регистратора колебаний на ERROR не останавливает эти вещи.

Ответы [ 2 ]

2 голосов
/ 31 марта 2011

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

public static synchronized void setDebugOn(boolean debugOn) {
    if (isAllDebugOn() ^ debugOn) {
        setAllDebugOn(debugOn);
        Enumeration en = LogManager.getCurrentLoggers();
        while (en.hasMoreElements()) {
            setDebugOn((Logger) en.nextElement(), debugOn);
        }
        setDebugOn(LogManager.getRootLogger(), debugOn);
    }
}

public static void setDebugOn(String name, boolean debugOn) {
    setDebugOn(getLogger(name), debugOn);
}

private static void setDebugOn(Logger logger, boolean debugOn) {
    logger.setLevel(debugOn ? Level.DEBUG : Level.INFO);
}

Другими словами, когда этот компонент помещается вВ режиме отладки он также переводит КАЖДЫЙ ОДИНОЧНЫЙ ЛОГГЕР LOG4J В WEBAPP в режим отладки (что я проверил, изменив код для вывода имени каждого регистратора внутри последнего метода из этих трех.)blammo - все сторонние вещи, которые используют log4j, начинают регистрировать свои выходные данные отладки независимо от того, что говорит log4j.properties. Sigh.

Когда я изменяю метод с этим циклом, чтобы связываться только с уровнямиопределенных регистраторов, связанных с этим компонентом, тогда моя конфигурация log4j.properties начинает работать как положено.

2 голосов
/ 30 марта 2011

Вы можете настроить log4j.properties так, чтобы получать только ваши журналы кода, как показано ниже, и помещать их в файл, отличный от catalina.out.

handlers = org.apache.juli.FileHandler

org.apache.juli.FileHandler.level = ALL org.apache.juli.FileHandler.directory = $ {catalina.base} / logs org.apache.juli.FileHandler.prefix = yourapp-name.

com.yourproject.module.package.level = ALL

...