CODEWITHSUNDEEP
javaloggingnullmember
user2610678
user2610678

Reputation:

Generic Java Logger output null.null for class and member name

I am using general java.util.logging.Logger with the following initialization line:

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

Then I use it like this (just an example):

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

In the log sometimes I can see the following:

24-Nov-2014 17:26:13.692 FINE [http-nio-80-exec-1] null.null Session id: 18BD6989930169F77565EA2D001A5759.

Most of the times times however it shows me the calling class and function correctly. That happens in other classes and members too. I cannot figure out why does this happen? Is it a bug in the Loggger?

Upvotes: 3

Views: 2824

Answers (2)

Reto Höhener
Reto Höhener

Reputation: 5808

I "solved" this by changing my custom LogFormatter to get the source class name and source method name at the very beginning of the format method.

The return values of these methods seem to have an "expiration date"...

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

So far, after that change I have not observed any null.null entries anymore, when before I had lots of them.

Upvotes: 0

jmehrens
jmehrens

Reputation: 11045

The output looks like it is from the 'org.apache.juli.OneLineFormatter' and the 'null.null' is the source class and source method names. From the LogRecord.getSourceMethodName documentation:

May be null if no information could be obtained.

It is possible it can't be determined or has been forced to null.

Looking at the source code for 'org.apache.juli.AsyncFileHandler' there is a bug where that code is not capturing the original callsite.

You can create and install a filter on the AsynchFileHandler to force compute the method and class names before a the thread hand off. Here is an example of such a filter:

    public class InferCallerFilter implements Filter {

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

Even the MemoryHandler included with the JDK gets this wrong. Per the LogRecord documentation:

Therefore, if a logging Handler wants to pass off a LogRecord to another thread, or to transmit it over RMI, and if it wishes to subsequently obtain method name or class name information it should call one of getSourceClassName or getSourceMethodName to force the values to be filled in.

Upvotes: 4

Related Questions