2014-11-25 2 views
2

Я использую общий java.util.logging.Logger со следующей строки инициализации:выход null.null Generic Java Logger для класса и член имени

private static final Logger _log = Logger.getLogger(Login.class.getName()); 

Тогда я использую его, как это (просто пример) :

_log.log(Level.FINE, "Session id: {0}.", session.getId()); 

В журнале иногда можно увидеть следующее:

24-ноября-2014 17: 26: 13,692 ВЫСОКОЕ [HTTP-NiO-80-Exec-1] null.null Сесси на id: 18BD6989930169F77565EA2D001A5759.

В большинстве случаев, однако, он показывает мне вызывающий класс и функцию правильно. Это происходит и в других классах и членах. Я не могу понять, почему это происходит? Это ошибка в Loggger?

+0

Это com.sun.enterprise.server.logging.UniformLogFormatter от GlassFish? Если да, то какая версия GF? – jmehrens

+0

Нет. К сожалению, я не упоминал имя пакета. Это java.util.logging.Logger. Я использую его с Tomcat. –

+0

Я также испытываю это с помощью tomcat (не изнутри затмения). Я использую свой собственный LogFormatter. – Zalumon

ответ

2

Результат выглядит так, как будто это из «org.apache.juli.OneLineFormatter», а «null.null» - это имена исходного и исходного методов. Из документации LogRecord.getSourceMethodName:

Может быть пустым, если информация не была получена.

Возможно, он не может быть определен или был forced to null.

Глядя на исходный код для «org.apache.juli.AsyncFileHandler» есть ошибка, где этот код не захватывая оригинал callsite.

Вы можете создать и install a filter на AsynchFileHandler, чтобы заставить вычислить имена методов и классов перед отключением потока. Ниже приведен пример такого фильтра:

public class InferCallerFilter implements Filter { 

     public boolean isLoggable(LogRecord record) { 
      record.getSourceMethodName(); //Infer caller. 
      return true; 
     } 
    } 

Даже MemoryHandler в комплекте с JDK gets this wrong. За документацией LogRecord:

Таким образом, если протоколирование Handler хочет передать покинуть LogRecord другому потоку, или передать его через RMI, и если он хочет, чтобы впоследствии получить имя метода или имя класса информации, которую он должен позвонить один из getSourceClassName или getSourceMethodName, чтобы заставить значение должны быть заполнено.

+0

Да, это очень возможно. Я не мог понять, когда он показывает нуль, и когда он работает нормально.В том же методе большую часть времени журнал работает отлично, но иногда он показывает нуль. –

+0

Если вы используете AsynchFileHandler, тогда переключите код на использование FileHander или установите InferCallerFilter, чтобы исключить ошибки передачи обслуживания. – jmehrens

0

Я «решен», изменив свой собственный LogFormatter, чтобы получить имя класса источника и источник имя методы в самом начале методы форматирования.

Возвращаемые значения этих методов, кажется, имеют «срок годности» ...

@Override 
    public String format(LogRecord record) 
    { 
    String sourceClassName = record.getSourceClassName(); 
    String sourceMethodName = record.getSourceMethodName(); 
    ... 
    } 

До сих пор, после этого изменения я не наблюдал каких-либо записей null.null больше, когда, прежде чем я имел много из них.

+0

Это не значит, что он истекает, когда первый поток вызывает [LogRecord.infercaller] (http://hg.openjdk.java.net/jdk8u/jdk8u60/jdk/file/935758609767/src/share/classes/java/ util/logging/LogRecord.java) навсегда побеждает. Именно поэтому javadocs предупреждает о вызове getSourceXXX до того, как произошла какая-либо передача потока. – jmehrens

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

  • Нет связанных вопросов^_^