What is Log4J and how do I use it?
Author: Deron Eriksson
Description: This Java tutorial gives an overview of how to use Log4J for logging in your applications.
Tutorial created using: Windows XP || JDK 1.5.0_09 || Eclipse Web Tools Platform 1.5.1

Page:    1 2 >

Log4j is a JavaSW library that specializes in logging. At the time of this writing, its home page is at http://logging.apache.org/log4j/docs/ . The Java library itself is available for download at http://logging.apache.org/site/binindex.cgi . The short manual at http://logging.apache.org/log4j/docs/manual.html does a great job covering many of the standard features of Log4j. At its most basic level, you can think of it as a replacement for System.out.println's in your code. Why is it better than System.out.println's? The reasons are numerous.

To begin with, System.out.println outputs to standard output, which typically is a console window. The output from Log4j can go to the console, but it can also go to an email server, a databaseW table, a log file, or various other destinations.

Another great benefit of Log4j is that different levels of logging can be set. The levels are hierarchical and are as follows: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. If you set a particular log level, messages will get logged for that level and all levels above it, and not for any log levels below that. As an example, if your log level is set to ERROR, you will log messages that are errors and fatals. If your log level is set to INFO, you will log messages that are infos, warns, errors, and fatals. Typically, when you develop on your local machine, it's good to set the log level to DEBUG, and when you deploy a web application, you should set the log level to INFO or higher so that you don't fill up your error logs with debug messages.

Log4j can do other great things. For instance, you can set levels for particular Java classes, so that if a particular class spits out lots of warnings, you can set the log level for that class to ERROR to suppress all the warning messages.

Typically, you can configure Log4j via a configuration file. This means that you can change your logging configuration without requiring code updates. If you need to do something like set the log level to DEBUG for your deployed application in order to track down a particular bug, you can do this without redeploying your application. Instead, you can change your log configuration file, reread the configuration file, and your logging configuration gets updated.

Let's try out Log4j. First off, we can download the log4j jarW file from the address mentioned above. I downloaded the jar file and added it to my project's build path.

'testing' project

I created a Log4JTest class. In this class, notice that I have a static Logger object called log, and this object is obtained from Logger.getLogger, with the Log4JTest class passed as a parameter to getLogger. This is basically saying that we have a Logger object that we can use in our Log4JTest class, and that the Log4JTest.class is the name that the logger is recognized as. In the main method, we have one log.debug call. Let's see what happens if we try to run our class at this stage.

Execution of Log4JTest

So, does this mean that Log4j doesn't work? Actually, if we read the console output, we can see that the problem is that we need to initialize Log4j. This is typically done via a Configurator. If we were using a properties file to set the logging configuration, we would use the PropertyConfigurator class, but for the sake of simplicity, let's use BasicConfigurator, which gives us a plain vanilla Log4j configuration without requiring any properties to be set. A call to the configure() method initializes Log4j, after which we can use the static Logger object in our class (and any other loggers throughout our application). If we now execute our class, we see the following:

Execution of Log4JTest containing BasicConfigurator.configure()

Log4j outputs our "This is a debug message" to the console. The number at the front of the line is the number of milliseconds since the application started. The [main] indicates the name of the thread. In addition, the line displays the log level (DEBUG) and the class name that we specified in our Logger.getLogger method call.

(Continued on page 2)

Page:    1 2 >