журналирования log4j дважды

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

public static void main(final String... args) throws Exception {

    LOGGER.info("program started");
    try {
        // try body codes
    } catch (Exception ex) {
        LOGGER.info("program start-up failed.",ex);
    }
}

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

6 57
logging log4j

6 ответов:

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

Это можно решить, установив аддитивности к false на вашем регистраторе. К log4j инструкцию упоминает аддитивность в разделе Приложения и макет.Проверьте это

80

согласен с Атлантидой. 

log4j.rootCategory=INFO, console
log4j.logger.org.hibernate=INFO

вышеуказанные параметры свойства вызовут двойное ведение журнала.

добавлять 
log4j.additivity.org.hibernate=false

Исправлена проблема.

страница 62 из этой книги. http://books.google.com/books?id=hZBimlxiyAcC&printsec=frontcover#v=onepage&q&f=false

32

для тех, кто использует формат XML:

<logger name="package.class" additivity="false">
    <level value="info" />
    <appender-ref ref="file" />
    <appender-ref ref="console" />
</logger>

примечание: по умолчанию для регистраторов установлен флаг аддитивности true.

29

просто добавить

logger.setadditivity(false);

в ваш код (ссылка).

у нас есть двойные результаты в консоли, это потому, что аппендеры не являются синглетами, они являются аддитивными. Это означает, что категория наследует все приложения от своих предков (по умолчанию). Если мы добавим приложение к категории, и он записывает в тот же базовый поток (консоль, тот же файл и т. д.) как и некоторые другие приложения, одно и то же сообщение журнала будет отображаться дважды (или более) в журнале. В кроме того, если две категории в иерархии настроены на использование одного и того же имени приложения, Log4j будет писать дважды в это приложение. Настроено для этой категории

3

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

Проверьте объект logger в отладчике. Если это организация.апаш.к log4j.Регистратор (в 1.2.x) тогда он может иметь AppenderAttachableImpl. Вы можете запросить AppenderAttachableImpl для списка приложений.

Если вы найдете более 1 приложения, это может быть проблемой - и ключ к его исправлению.

2

потенциальная Альтернатива для регулировки additivity свойство состоит в том, чтобы изучить ваши регистраторы от наиболее конкретных до наиболее общих. В следующем примере мы ожидаем увидеть двойное ведение журнала в консоли для любых событий журнала, происходящих в foo.бар.LoggingExampleClass. Было бы безопасно удалить дополнительный консольный аппендер из foo.бар.LoggingExampleClass Logger, поскольку он уже покрыт корневым регистратором.

<Logger name="foo.bar.LoggingExampleClass" level="DEBUG">
  <AppenderRef ref="Console" />   <!-- THIS APPENDER COULD BE REMOVED -->
  <AppenderRef ref="FooBarPackageLogging" />
</Logger>

<Root level="WARN">
  <AppenderRef ref="Console" />
  <AppenderRef ref="MainLogFile" />
</Root>

есть компромиссы как для регулировки аддитивности подход и подход к настройке приложения. Отключение аддитивности может непреднамеренно остановить использование приложения регистратора желаемого общего уровня. В приведенном выше примере, установка additivity="false" свойство на foo.бар.LoggingExampleClass Logger будет означать, что событие ведения журнала не будет добавлено к MainLogFile, на который ссылается корневой регистратор.

С другой стороны, полагаться на родительские приложения может быть проблематично, если родительские приложения будут изменены без изучения влияние на более зернистые лесозаготовители. Например, предположим, что существует требование, что foo.бар.LoggingExampleClass события ведения журнала должны быть записаны на консоль. Они в настоящее время находятся в приведенной выше конфигурации примера из-за аддитивности, даже если foo.бар.Приложение консоли Loggingexampleclass Logger удаляется. Однако если приложение консоли также было удалено из корневого регистратора без каких-либо дополнительных настроек, это требование больше не будет выполнено.

0