2016-09-15 2 views
2

Я пытаюсь использовать Log4j2 в среде OSGi. У меня есть работа до сих пор, но, проверяя журналы с консоли и из файла, я заметил, что некоторые из них отсутствовали, особенно журналы, которые вызывались из статического метода. Класс Log в приведенном ниже примере - это класс удобства, позволяющий моим коллегам более легко вызвать функцию ведения журнала (в примере только для String это похоже на излишний уровень) через метод создания. Он не более чем создает экземпляр класса журнала, который внутренне имеет Logger, который вызывает соответствующий метод из регистратора Log4j2.журнал из статического метода с использованием Log4j2

Мой вопрос: есть ли у меня простая ошибка в моем проекте или Log4j2 не способен записывать файлы из статических методов?

Вот пример кода, чтобы сделать его немного более ясно:

Log log = Log.testLog(); 
    log.info("non static log"); 

Это код, который я называю из не статического метода. А вот testLog() -метода:

public static Log testLog() { 
    Log.create(Log.class).info("static log"); 
    return Log.create(Log.class); 
} 

Результатов: Оба #info() вызовов запись в консоли Appender, но сообщение только «не статический журнала» записываются в файл.

Вот мой log4j2.xml:

<?xml version="1.0" encoding="UTF-8"?> 
<Configuration> 


<Appenders> 
    <Console name="Console"> 
     <PatternLayout pattern="!ENTRY %logger{1.} %level %d{DEFAULT} [%t]%n!MESSAGE %msg%n%n"/> 
    </Console> 

    <RollingFile name="RollingFile" fileName="${sys:osgi.logfile}.log4j.log" 
      filePattern="${sys:osgi.logfile}.log4j_bak_%i.log"> 
     <PatternLayout> 
      <pattern>!ENTRY %logger{1.} %level %d{DEFAULT} [%t]\n!MESSAGE %msg%n%n</pattern> 
     </PatternLayout> 
     <Policies> 
      <SizeBasedTriggeringPolicy size="1 MB"/> 
     </Policies> 
     <DefaultRolloverStrategy max="10" 
      fileIndex="min"/> 
    </RollingFile> 
    </Appenders> 

    <Loggers> 
    <Root level="TRACE" additivity="false"> 
     <AppenderRef ref="RollingFile"/> 
     <AppenderRef ref="Console"/> 
    </Root> 
    </Loggers> 
</Configuration> 
+0

Почему вы просто не вызываете 'Log.create (Log.class)' once? – Thomas

+0

Это что-то изменит? Это действительно не причина, я просто быстро ударил метод вместе для целей тестирования. –

+0

Я не уверен, но я мог представить, что воссоздание экземпляра «Журнал» может очистить буфер. Кроме того, мы обычно используем обертку вокруг log4j, такую ​​как slf4j или ведение журнала сообщества, и, таким образом, используем фабрику для создания регистраторов, но AFAIK log4j предоставляет что-то похожее, возможно, по той же причине, то есть вы должны создать определенный логгер только один раз, а затем повторно использовать этот экземпляр. – Thomas

ответ

1

Наконец нашел источник моей конкретной проблемы, которая является OSGi (в данном случае Equinox Framework). В моем приложении используется системное свойство osgi.logfile, чтобы указать на место, где должны храниться журналы.

К сожалению, Equinox не только создает это свойство, но и изменяет его при запуске в другое место. Для Log4j2 я использовал ${sys:osgi.logfile}, чтобы получить это системное свойство, но поскольку несколько отдельных плагинов начались так рано, у Log4j2 все еще было неправильное расположение (старое), настроенное для этих плагинов (точнее: их LoggerContext).

Что помогло мне в этом случае было просто LoggerContext.reconfigure() на LoggerContext, который все еще был в старом месте.

Смежные вопросы