Why calling LoggerFactory.getLogger(…) every time is not recommended?

Question

I\'ve read tons of posts and documents (on this site and elsewhere) pointing that the recommended pattern for SFL4J logging is:

public class MyClass {
    fi         


        

Answer 1

To add to the reasons already mentioned, your boss's suggestion is bad because:

• It forces you to repeatedly type something that has nothing to with logging, every time you want to log something: this.getClass()
• Creates a non-uniform interface between static and non-static contexts (because there is no this in a static context)
• The additional unnecessary parameters creates room for error, makes it possible for statements in the same class to go to different loggers (think careless copy pasting)
• While it saves 74 characters of logger declaration, it adds 27 extra characters to each logging call. This means if a class uses the logger more than 2 times, you're increasing boilerplate code in terms of character count.

Answer 2

When using something like: MyLoggerWrapper.debug(this.getClass(), "blah") You will get wrong classnames when using AOP frameworks or code-injection tools. The classnames are not like the origin, but a generated classname. And another drawback of using the wrapper: For every log statement, you must include additional code "MyClass.class".

The 'caching' of the loggers depends on the used frameworks. But even when it does, it must still look up the desired logger for every log statement you make. So having 3 statements in a method, it must look it up 3 times. Using it as a static variable it must only look it up once!

And said before: you lose the ability to use if( log.isXXXEnabled() ){} for a set of statements.

What has your boss against the "community default accepted and recommended way"? Introducing the wrapper is not adding more efficiency. Instead you must use the classname for every log statement. After a while you want to "improve" that, so you add another variable, or another wrapper making it more difficult for yourself.

Answer 3

No. Not other than it messes up the call stack. That disrupts the methods that allow you to see the method name and class of the code doing the log.

You may consider having a look at the Jetty web container which contains their own abstraction which builds on top of slf4j. Very nice.

Answer 4

The logger objects are surely reused, so no extra instantation is going to happen either way. The bigger problem I see is that your file/line number info will be useless, since the logger will always faithfully log that each message was issued from class LoggerWrapper, line 12 :-(

OTOH SLF4J is already a wrapper facade to hide the specific logging framework used, allowing you to freely change between different logging implementations. Therefore I see absolutely no point in hiding that behind yet another wrapper.

Answer 5

I just have to say that the recommended pattern is easiest to read and implement. I see no reason for straying from it. Especially no benefit.

However, my main point is about the guards mentioned previously. I would not recommend explicitly guarding your logs as this is already done internally by log4j and is a duplication of effort.

Download the source for log4j and have a look at the Logger and Category classes to see for yourself.