Java Logging with log4J Framework
_
IInstallation : Download Log4J from the Jakarta site. The URL is http://jakarta.apache.org/log4j/docs/download.html. Now, unzip the file. The file of our interest is dist\lib\log4j-1.2.7.jar. Place this file in the classpath.
About Log4J : Inserting log statements into code is a low-tech method for debugging it. Logging does have its drawbacks. It can slow down an application. To alleviate these concerns, log4j is designed to be reliable, fast and extensible. The first and foremost advantage of any logging API over plain System.out.println resides in its ability to disable certain log statements while allowing others to print unhindered.
Logger : Log4j uses a class "Logger". Loggers are named entities. Logger names are case-sensitive and they follow the hierarchical naming rule. A logger is said to be an ancestor of another logger if its name followed by a dot is a prefix of the descendant logger name. A logger is said to be a parent of a child logger if there are no ancestors between itself and the descendant logger. 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".
The root logger resides at the top of the logger hierarchy. It is exceptional in two ways:
- it always exists,
- it cannot be retrieved by name.
Invoking the static Logger.getRootLogger() method retrieves the root logger. All other loggers are instantiated and retrieved with the static Logger.getLogger() method. This method takes the name of the desired logger as a parameter. The methods of the Logger class that are used to obtain a logger are - * public static Logger getLogger(String name)
Retrieve a logger by name.
* public static Logger getLogger(Class clazz)
Same as calling getLogger(clazz.getName()).
Levels : Loggers may be assigned levels. There are some built-in levels defined in the org.apache.log4j.Level class. They are DEBUG : designates fine-grained informational events that are most
useful to debug an application.
INFO : designates informational messages that highlight the
progress of the application at coarse-grained level.
WARN : designates potentially harmful situations.
ERROR : designates error events that might still allow the
application to continue running.
FATAL : designates very severe error events that will presumably
lead the application to abort.
We may define our own levels by sub-classing the Level class. If a given logger is not assigned a level, then it inherits one from its closest ancestor with an assigned level. To ensure that all loggers can eventually inherit a level, the root logger always has an assigned level.
Logging : Logging requests are made by invoking one of the printing methods of a logger instance. These printing methods are defined in the class org.apache.log4j.Logger. The methods are -
DEBUG < INFO < WARN < ERROR < FATAL
Appenders : An output destination is called an appender (where the log is sent). Currently, appenders exist for the console, files, GUI components, remote socket servers, JMS, NT Event Loggers, and remote UNIX Syslog daemons. It is also possible to log asynchronously. More than one appender can be attached to a logger.
We can add an appender to a logger by using the method
public void addAppender(Appender newAppender)
Just like levels, appenders are also inherited by a child from it's parent. For example, if a console appender is added to the root logger, then all enabled logging requests will at least print on the console. If in addition a file appender is added to a logger, say C, then enabled logging requests for C and C's children will print on a file and on the console. It is possible to override this default behavior so that appender accumulation is no longer additive by setting the additivity flag to false.
About Log4J : Inserting log statements into code is a low-tech method for debugging it. Logging does have its drawbacks. It can slow down an application. To alleviate these concerns, log4j is designed to be reliable, fast and extensible. The first and foremost advantage of any logging API over plain System.out.println resides in its ability to disable certain log statements while allowing others to print unhindered.
Logger : Log4j uses a class "Logger". Loggers are named entities. Logger names are case-sensitive and they follow the hierarchical naming rule. A logger is said to be an ancestor of another logger if its name followed by a dot is a prefix of the descendant logger name. A logger is said to be a parent of a child logger if there are no ancestors between itself and the descendant logger. 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".
The root logger resides at the top of the logger hierarchy. It is exceptional in two ways:
- it always exists,
- it cannot be retrieved by name.
Invoking the static Logger.getRootLogger() method retrieves the root logger. All other loggers are instantiated and retrieved with the static Logger.getLogger() method. This method takes the name of the desired logger as a parameter. The methods of the Logger class that are used to obtain a logger are - * public static Logger getLogger(String name)
Retrieve a logger by name.
* public static Logger getLogger(Class clazz)
Same as calling getLogger(clazz.getName()).
Levels : Loggers may be assigned levels. There are some built-in levels defined in the org.apache.log4j.Level class. They are DEBUG : designates fine-grained informational events that are most
useful to debug an application.
INFO : designates informational messages that highlight the
progress of the application at coarse-grained level.
WARN : designates potentially harmful situations.
ERROR : designates error events that might still allow the
application to continue running.
FATAL : designates very severe error events that will presumably
lead the application to abort.
We may define our own levels by sub-classing the Level class. If a given logger is not assigned a level, then it inherits one from its closest ancestor with an assigned level. To ensure that all loggers can eventually inherit a level, the root logger always has an assigned level.
Logging : Logging requests are made by invoking one of the printing methods of a logger instance. These printing methods are defined in the class org.apache.log4j.Logger. The methods are -
- public void debug(Object message) : Logs a message object with the DEBUG level.
- public void info(Object message) : Logs a message object with the INFO Level.
- public void warn(Object message) : Logs a message object with the WARN Level.
- public void error(Object message) : Logs a message object with the ERROR Level.
- public void fatal(Object message) : Logs a message object with the FATAL Level.
DEBUG < INFO < WARN < ERROR < FATAL
Appenders : An output destination is called an appender (where the log is sent). Currently, appenders exist for the console, files, GUI components, remote socket servers, JMS, NT Event Loggers, and remote UNIX Syslog daemons. It is also possible to log asynchronously. More than one appender can be attached to a logger.
We can add an appender to a logger by using the method
public void addAppender(Appender newAppender)
Just like levels, appenders are also inherited by a child from it's parent. For example, if a console appender is added to the root logger, then all enabled logging requests will at least print on the console. If in addition a file appender is added to a logger, say C, then enabled logging requests for C and C's children will print on a file and on the console. It is possible to override this default behavior so that appender accumulation is no longer additive by setting the additivity flag to false.
