log4j

The first and foremost advantage of any logging API over plain System.out.println resides in
For example, the logger named "com.foo" is a parent of the logger named "com.foo.Bar". Similarly, "java" is a parent of "java.util" and an ancestor of "java.util.Vector". This naming scheme should be familiar to most developers.
By definition, the printing method determines the level of a logging request.
This rule is at the heart of log4j
The developer is free to name the loggers as desired
seems to be the best strategy known so far.
If in addition a file appender is added to a logger, say C, then enabled logging requests forC and C's children will print on a file and on the console.
More often than not, users wish to customize not only the output destination but also the output format.
The layout is responsible for formatting the logging request according to the user's wishes,
whereas an appender takes care of sending the formatted output to its destination
Just as importantly, log4j will render the content of the log message according to user specified criteria.
Inserting log requests into the application code requires a fair amount of planning and effort.
Observation shows that approximately 4 percent of code is dedicated to logging. Consequently, even moderately sized applications will have thousands of logging statements embedded within their code.
Let us give a taste of how this is done with the help of an imaginary application MyApp that uses log4j.
The figure below depicts the object diagram of MyApp after just having called the BasicConfigurator.configure method.

As a side note, let me mention that