I am stuck at understanding a concept related to Logger creation, especially in the context of Java EE.
In my experience, I nearly always used one logger per application, with few cases when I needed a specific logger for a specific part of the application. Only in these cases I was creating through my wrapper a new logger. And, if we talk about identifying the class which called the logger, I was doing a simple thing:
public const String ThisIdentifier = "MyLoggerCallingClass";
And I was passing this as a parameter to the logger method, even if there were some additional keystrokes I needed to do.
Now I'm facing a conceptual problem:
Why create logger per class, and not one per application.
I have found the following answers:
However, if I get this info from apache documentation on getLogger:
Retrieve a logger named according to the value of the name parameter. If the named logger already exists, then the existing instance will be returned. Otherwise, a new instance is created.
I understand that if I do the per class way, and let's say that I have 50 packages in a Java EE application, and 10 classes per package, I will have 500 logger instances in my app!
I come from a C, C++ and C# perspective, and always in my mind I have the following:
"Use memory sparingly, create instances only as needed, cleanup after yourself, don't abuse etc..."
I don't know the actual details of the logger creation, and I understand the idea of being able to better filter log results, but can anyone explain me why to go that way and how useful it is in the end, to create instance per class, why waste memory and have many instances, instead of just calling a logger method with a parameter?
While maybe it's true, that in general people do not care about the many so called "lightweight" logger instances created, I ended up with my colleagues on the project to create a wrapper class for log4j, that I instance in every class where I want to use logger. This wrapper class contains a reference to a single instance of logger by default
and also the name of the class where this specific logger is called, so to log the logging class name. In the case when I will need specific classes to be logged, I will just change the
rebuild the app and run it. In my opinion this solution seems more clean and neat.
Found out this:
Based on our previous work on log4j, logback internals have been re-written to perform about ten times faster on certain critical execution paths. Not only are logback components faster, they have a smaller memory footprint as well
Based on the quote above, in which we can clearly see the phrase containing "smaller memory footprint", I can make the conclusion that my suspicions weren't so false. With the team we now take into the consideration the idea of switching to logback if we will be able to achieve the same logging functionality we need and do with log4j.
Hope that this question helps others make the right decision!