Cons for defining logger non-static

Comments for this answer http://stackoverflow.com/questions/212697/how-do-you-reduce-java-logging-boilerplate-code#212753 strongly suggest not to use loggers as instance member variables. I can think of two negative side-effects:
1) superclass logs with the subclass's logger
2) object cannot be serialized (unless marked transient)

But if serializing is not necessary and logging with subclass name is not a problem, is there anything else why it should be avoided? I think it reduces boilerplate code and avoids copy-paste errors while copying logger variable definition from one class to another. Even Spring framework (which I believe has very good coding standards) uses this method.

From stackoverflow

• Try debugging an error where you see a message generated by the SuperClass class when the error is really being logged in the SubClass class. I've seen several situations where developers create a LoggingUtils class which generates messages which generally duplicate the things which are already baked-in by the logging framework.

  The only real situation I see for using a shared logging instance is something like the Apache commons HttpClient logger httpclient.wire which is shared between several classes for logging the contents of the requests and responses sent through the client. This particular logging situation does not log information for the actual implementation of the package, it logs information about the whole http "transaction".

• Another, probably minor con: wasted memory, especially when you have lots of instances, each one with its own logger

  martsraits : Log4j (I presume other logging frameworks also) holds a pool of loggers. So only one instance with the same name is created. So memory consumption is the same as with static loggers.

  Ashutosh Singh : if this is con then better to use singelton

  Yoni Roit : @martsraits: No, because your class holds a new reference (pointer) to the pooled instance

• The major difference asides from the Superclass logging with subclass name, of course, is that you'll have one Logger object per member of your class. Depending on how many classes are using logging, this can be a huge amount of Loggers, so memory bloat may be an issue.

  Plus from an abstract point of view, the logger really does belong to the class and can be shared between all instances, rather than each instance needing its own private copy, so it makes sense to declare it as static. Flipping your question around, what advantages does it have to making it non-static? (Being able to pass getClass() into the getLogger() call instead of passing in the class constant is the only thing I can think of, and that's such a tiny thing).

  martsraits : Log4j (I presume other logging frameworks also) holds a pool of loggers. So only one instance with the same name is created. So memory consumption is the same as with static loggers.

  martsraits : As a pro I also mentioned reducing boilerplate code.

• If your Logger is an instance member instead of static, the Logger has to be retrieved every time a new object is created. Albeit this overhead is probably insignificant, but it's one disadvantage.

  From a design perspective, Loggers aren't really a property of an object, since they're usually meta-information about your system rather than business information within the system itself. A Logger isn't really part of something like a Car object in the same way an Engine or a Transmission is. Tying Loggers to objects as members (in most cases) doesn't make sense semantically more than anything.