Apache log4j 1.2 Short introduction to log4j (2024)

Logger hierarchy

The first and foremost advantage of any logging API over plainSystem.out.println resides in its ability to disablecertain log statements while allowing others to print unhindered. Thiscapability assumes that the logging space, that is, the space of allpossible logging statements, is categorized according to somedeveloper-chosen criteria. This observation had previously led us tochoose category as the central concept of thepackage. However, since log4j version 1.2, Logger classhas replaced the Category class. For those familiar withearlier versions of log4j, the Logger class can beconsidered as a mere alias to the Category class.

Loggers are named entities. Logger names are case-sensitive andthey follow the hierarchical naming rule:

For example, the logger named "com.foo" is a parentof the logger named "com.foo.Bar". Similarly,"java" is a parent of "java.util" and anancestor of "java.util.Vector". This naming schemeshould be familiar to most developers.

The root logger resides at the top of the logger hierarchy. Itis exceptional in two ways:

1. it always exists,
2. it cannot be retrieved by name.

Invoking the class static Logger.getRootLoggermethod retrieves it. All other loggers are instantiated andretrieved with the class static Logger.getLoggermethod. This method takes the name of the desired logger as aparameter. Some of the basic methods in the Logger class are listedbelow.

 package org.apache.log4j; public class Logger { // Creation & retrieval methods: public static Logger getRootLogger(); public static Logger getLogger(String name); // printing methods: public void trace(Object message); public void debug(Object message); public void info(Object message); public void warn(Object message); public void error(Object message); public void fatal(Object message); // generic printing method: public void log(Level l, Object message);}

If a given logger is not assigned a level, then it inheritsone from its closest ancestor with an assigned level. Moreformally:

To ensure that all loggers can eventually inherit a level,the root logger always has an assigned level.

Below are four tables with various assigned level values and theresulting inherited levels according to the above rule.

In example 1 above, only the root logger is assigned alevel. This level value, Proot, is inherited by theother loggers X, X.Y andX.Y.Z.

In example 2, all loggers have an assigned level value. Thereis no need for level inheritence.

In example 3, the loggers root, X andX.Y.Z are assigned the levels Proot,Px and Pxyz respectively. The loggerX.Y inherits its level value from its parentX.

In example 4, the loggers root and Xand are assigned the levels Proot and Pxrespectively. The loggers X.Y and X.Y.Zinherits their level value from their nearest parent Xhaving an assigned level..

Logging requests are made by invoking one of the printing methodsof a logger instance. These printing methods aredebug,info,warn,error,fatal and log.

By definition, the printing method determines the level of alogging request. For example, if c is a loggerinstance, then the statement c.info("..") is a loggingrequest of level INFO.

A logging request is said to be enabled if its level ishigher than or equal to the level of its logger. Otherwise, therequest is said to be disabled. A logger without anassigned level will inherit one from the hierarchy. This rule issummarized below.

This rule is at the heart of log4j. It assumes that levels areordered. For the standard levels, we have DEBUG < INFO< WARN < ERROR < FATAL.

Here is an example of this rule.

 // get a logger instance named "com.foo" Logger logger = Logger.getLogger("com.foo"); // Now set its level. Normally you do not need to set the // level of a logger programmatically. This is usually done // in configuration files. logger.setLevel(Level.INFO); Logger barlogger = Logger.getLogger("com.foo.Bar"); // This request is enabled, because WARN >= INFO. logger.warn("Low fuel level."); // This request is disabled, because DEBUG < INFO. logger.debug("Starting search for nearest gas station."); // The logger instance barlogger, named "com.foo.Bar", // will inherit its level from the logger named // "com.foo" Thus, the following request is enabled // because INFO >= INFO. barlogger.info("Located nearest gas station."); // This request is disabled, because DEBUG < INFO. barlogger.debug("Exiting gas station search");

Calling the getLogger method with the same name willalways return a reference to the exact same logger object.

For example, in

 Logger x = Logger.getLogger("wombat"); Logger y = Logger.getLogger("wombat");

and

refer to exactly the samelogger object.

Thus, it is possible to configure a logger and then to retrievethe same instance somewhere else in the code without passing aroundreferences. In fundamental contradiction to biological parenthood,where parents always preceed their children, log4j loggers can becreated and configured in any order. In particular, a "parent"logger will find and link to its descendants even if it isinstantiated after them.

Configuration of the log4j environment is typically done atapplication initialization. The preferred way is by reading aconfiguration file. This approach will be discussed shortly.

Log4j makes it easy to name loggers by softwarecomponent. This can be accomplished by statically instantiatinga logger in each class, with the logger name equal to the fullyqualified name of the class. This is a useful and straightforwardmethod of defining loggers. As the log output bears the name of thegenerating logger, this naming strategy makes it easy to identifythe origin of a log message. However, this is only one possible,albeit common, strategy for naming loggers. Log4j does not restrictthe possible set of loggers. The developer is free to name theloggers as desired.

Nevertheless, naming loggers after the class where they arelocated seems to be the best strategy known so far.

Appenders and Layouts

The ability to selectively enable or disable logging requests basedon their logger is only part of the picture. Log4j allows loggingrequests to print to multiple destinations. In log4j speak, an outputdestination is called an appender. Currently, appenders existfor the console, files, GUIcomponents, remote socketservers, JMS, NTEvent Loggers, and remote UNIX Syslogdaemons. It is also possible to log asynchronously.

More than one appender can be attached to a logger.

The addAppendermethod adds an appender to a given logger.Each enabled loggingrequest for a given logger will be forwarded to all the appenders inthat logger as well as the appenders higher in the hierarchy. Inother words, appenders are inherited additively from the loggerhierarchy. For example, if a console appender is added to the rootlogger, then all enabled logging requests will at least print on theconsole. If in addition a file appender is added to a logger, sayC, then enabled logging requests for C andC's children will print on a file and on theconsole. It is possible to override this default behavior so thatappender accumulation is no longer additive by settingthe additivity flag to false.

The rules governing appender additivity are summarized below.

The table below shows an example:

More often than not, users wish to customize not only the outputdestination but also the output format. This is accomplished byassociating a layout with an appender. The layout isresponsible for formatting the logging request according to the user'swishes, whereas an appender takes care of sending the formatted outputto its destination.

The PatternLayout, partof the standard log4j distribution, lets the user specify the outputformat according to conversion patterns similar to the C language

function.

For example, the PatternLayout with the conversion pattern "%r [%t]%-5p %c - %m%n" will output something akin to:

176 [main] INFO org.foo.Bar - Located nearest gas station.

The first field is the number of milliseconds elapsed since thestart of the program. The second field is the thread making the logrequest. The third field is the level of the log statement. Thefourth field is the name of the logger associated with the logrequest. The text after the '-' is the message of the statement.

Just as importantly, log4j will render the content of the logmessage according to user specified criteria. For example, if youfrequently need to log Oranges, an object type used inyour current project, then you can register anOrangeRenderer that will be invoked whenever an orangeneeds to be logged.

Object rendering follows the class hierarchy. For example, assumingoranges are fruits, if you register a FruitRenderer, allfruits including oranges will be rendered by theFruitRenderer, unless of course you registered an orangespecific OrangeRenderer.

Object renderers have to implement theObjectRendererinterface.

Configuration

Inserting log requests into the application code requires a fairamount of planning and effort. Observation shows that approximately 4percent of code is dedicated to logging. Consequently, even moderatelysized applications will have thousands of logging statements embeddedwithin their code. Given their number, it becomes imperative tomanage these log statements without the need to modify them manually.

The log4j environment is fully configurable programmatically.However, it is far more flexible to configure log4j usingconfiguration files. Currently, configuration files can be written inXML or in Java properties (key=value) format.

Let us give a taste of how this is done with the help of animaginary application MyApp that uses log4j.

 import com.foo.Bar; // Import log4j classes. import org.apache.log4j.Logger; import org.apache.log4j.BasicConfigurator; public class MyApp { // Define a static logger variable so that it references the // Logger instance named "MyApp". static Logger logger = Logger.getLogger(MyApp.class); public static void main(String[] args) { // Set up a simple configuration that logs on the console. BasicConfigurator.configure(); logger.info("Entering application."); Bar bar = new Bar(); bar.doIt(); logger.info("Exiting application."); } }

MyApp begins by importing log4j related classes. Itthen defines a static logger variable with the nameMyApp which happens to be the fully qualified name of theclass.

MyApp uses the Bar class defined in thepackage com.foo.

 package com.foo; import org.apache.log4j.Logger; public class Bar { static Logger logger = Logger.getLogger(Bar.class); public void doIt() { logger.debug("Did it again!"); } }

The invocation of the BasicConfigurator.configuremethod creates a rather simple log4j setup. This method is hardwiredto add to the root logger a ConsoleAppender. The output will be formatted using a PatternLayout setto the pattern "%-4r [%t] %-5p %c %x - %m%n".

Note that by default, the root logger is assigned toLevel.DEBUG.

The output of MyApp is:

0 [main] INFO MyApp - Entering application.36 [main] DEBUG com.foo.Bar - Did it again!51 [main] INFO MyApp - Exiting application.

The figure below depicts the object diagram of MyAppafter just having called the BasicConfigurator.configuremethod.

As a side note, let me mention that in log4j child loggers linkonly to their existing ancestors. In particular, the logger namedcom.foo.Bar is linked directly to the rootlogger, thereby circumventing the unused com orcom.foo loggers. This significantly increasesperformance and reduces log4j's memory footprint.

The MyApp class configures log4j by invokingBasicConfigurator.configure method. Other classes onlyneed to import the org.apache.log4j.Logger class,retrieve the loggers they wish to use, and log away.

The previous example always outputs the same log information.Fortunately, it is easy to modify MyApp so that the logoutput can be controlled at run-time. Here is a slightly modifiedversion.

 import com.foo.Bar; import org.apache.log4j.Logger; import org.apache.log4j.PropertyConfigurator; public class MyApp { static Logger logger = Logger.getLogger(MyApp.class.getName()); public static void main(String[] args) { // BasicConfigurator replaced with PropertyConfigurator. PropertyConfigurator.configure(args[0]); logger.info("Entering application."); Bar bar = new Bar(); bar.doIt(); logger.info("Exiting application."); } }

This version of MyApp instructsPropertyConfigurator to parse a configuration file andset up logging accordingly.

Here is a sample configuration file that results in identicaloutput as the previous BasicConfigurator based example.

# Set root logger level to DEBUG and its only appender to A1.log4j.rootLogger=DEBUG, A1# A1 is set to be a ConsoleAppender.log4j.appender.A1=org.apache.log4j.ConsoleAppender# A1 uses PatternLayout.log4j.appender.A1.layout=org.apache.log4j.PatternLayoutlog4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

Suppose we are no longer interested in seeing the output of anycomponent belonging to the com.foo package. The followingconfiguration file shows one possible way of achieving this.

log4j.rootLogger=DEBUG, A1log4j.appender.A1=org.apache.log4j.ConsoleAppenderlog4j.appender.A1.layout=org.apache.log4j.PatternLayout# Print the date in ISO 8601 formatlog4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n# Print only messages of level WARN or above in the package com.foo.log4j.logger.com.foo=WARN

The output of MyApp configured with this file is shown below.

2000-09-07 14:07:41,508 [main] INFO MyApp - Entering application.2000-09-07 14:07:41,529 [main] INFO MyApp - Exiting application.

As the logger com.foo.Bar does not have an assignedlevel, it inherits its level from com.foo, whichwas set to WARN in the configuration file. The log statement from theBar.doIt method has the level DEBUG, lower than thelogger level WARN. Consequently, doIt() method's logrequest is suppressed.

Here is another configuration file that uses multiple appenders.

log4j.rootLogger=debug, stdout, Rlog4j.appender.stdout=org.apache.log4j.ConsoleAppenderlog4j.appender.stdout.layout=org.apache.log4j.PatternLayout# Pattern to output the caller's file name and line number.log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%nlog4j.appender.R=org.apache.log4j.RollingFileAppenderlog4j.appender.R.File=example.loglog4j.appender.R.MaxFileSize=100KB# Keep one backup filelog4j.appender.R.MaxBackupIndex=1log4j.appender.R.layout=org.apache.log4j.PatternLayoutlog4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

Calling the enhanced MyApp with the this configuration file willoutput the following on the console.

 INFO [main] (MyApp2.java:12) - Entering application.DEBUG [main] (Bar.java:8) - Doing it again! INFO [main] (MyApp2.java:15) - Exiting application.

In addition, as the root logger has been allocated a secondappender, output will also be directed to the example.logfile. This file will be rolled over when it reaches 100KB. Whenroll-over occurs, the old version of example.log isautomatically moved to example.log.1.

Note that to obtain these different logging behaviors we did notneed to recompile code. We could just as easily have logged to a UNIXSyslog daemon, redirected all com.foo output to an NTEvent logger, or forwarded logging events to a remote log4j server,which would log according to local server policy, for example byforwarding the log event to a second log4j server.

Default Initialization Procedure

The log4j library does not make any assumptions about itsenvironment. In particular, there are no default log4jappenders. Under certain well-defined circ*mstances however, thestatic inializer of the Logger class will attempt toautomatically configure log4j. The Java language guarantees that thestatic initializer of a class is called once and only once during theloading of a class into memory. It is important to remember thatdifferent classloaders may load distinct copies of the sameclass. These copies of the same class are considered as totallyunrelated by the JVM.

The default initialization is very useful in environments where theexact entry point to the application depends on the runtimeenvironment. For example, the same application can be used as astand-alone application, as an applet, or as a servlet under thecontrol of a web-server.

The exact default initialization algorithm is defined as follows:

1. Setting the log4j.defaultInitOverride system property to any other value then "false" will cause log4j to skip the default initialization procedure (this procedure).
2. Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resource to its default value "log4j.properties".
3. Attempt to convert the resource variable to a URL.
4. If the resource variable cannot be converted to a URL, for example due to a MalformedURLException, then search for the resource from the classpath by calling org.apache.log4j.helpers.Loader.getResource(resource, Logger.class) which returns a URL. Note that the string "log4j.properties" constitutes a malformed URL.

   See Loader.getResource(java.lang.String) for the list of searched locations.

5. If no URL could not be found, abort default initialization. Otherwise, configure log4j from the URL.

   The PropertyConfigurator will be used to parse the URL to configure log4j unless the URL ends with the ".xml" extension, in which case the DOMConfigurator will be used. You can optionaly specify a custom configurator. The value of the log4j.configuratorClass system property is taken as the fully qualified class name of your custom configurator. The custom configurator you specify must implement the Configurator interface.

Example Configurations

Default Initialization under Tomcat

The default log4j initialization is particularly useful inweb-server environments. Under Tomcat 3.x and 4.x, you should placethe log4j.properties under theWEB-INF/classes directory of your web-applications. Log4jwill find the properties file and initialize itself. This is easy todo and it works.

You can also choose to set the system propertylog4j.configuration before starting Tomcat. For Tomcat 3.x TheTOMCAT_OPTS environment variable is used to set commandline options. For Tomcat 4.0, set the CATALINA_OPTSenvironment variable instead of TOMCAT_OPTS.

Example 1

The Unix shell command

 export TOMCAT_OPTS="-Dlog4j.configuration=foobar.txt"

tells log4j to use the file

foobar.txt

as the defaultconfiguration file. This file should be place under the

WEB-INF/classes

directory of your web-application. Thefile will be read using the PropertyConfigurator. Eachweb-application will use a different default configuration file becauseeach file is relative to a web-application.

Example 2

The Unix shell command

 export TOMCAT_OPTS="-Dlog4j.debug -Dlog4j.configuration=foobar.xml"

tells log4j to output log4j-internal debugging information and to usethe file

foobar.xml

as the default configurationfile. This file should be place under the

WEB-INF/classes

directory of your web-application. Since the file ends with a

.xml

extension, it will read using the DOMConfigurator. Eachweb-application will use a different default configuration file becauseeach file is relative to a web-application.

Example 3

The Windows shell command

 set TOMCAT_OPTS=-Dlog4j.configuration=foobar.lcf -Dlog4j.configuratorClass=com.foo.BarConfigurator

tells log4j to use the file

foobar.lcf

as the defaultconfiguration file. This file should be place under the

WEB-INF/classes

directory of your web-application. Due tothe definition of the log4j.configuratorClass system property,the file will be read using the

com.foo.BarConfigurator

custom configurator. Each web-application will use a differentdefault configuration file because each file is relative to aweb-application.

Example 4

The Windows shell command

 set TOMCAT_OPTS=-Dlog4j.configuration=file:/c:/foobar.lcf

tells log4j to use the file

c:\foobar.lcf

as the defaultconfiguration file. The configuration file is fully specified by theURL

file:/c:/foobar.lcf

. Thus, the same configurationfile will be used for all web-applications.

Different web-applications will load the log4j classes throughtheir respective classloaderss. Thus, each image of the log4jenvironment will act independetly and without any mutualsynchronization. For example, FileAppenders definedexactly the same way in multiple web-application configurations willall attempt to write the same file. The results are likely to be lessthan satisfactory. You must make sure that log4j configurations ofdifferent web-applications do not use the same underlying systemresource.

Initialization servlet

It is also possible to use a special servlet for log4jinitialization. Here is an example,

package com.foo;import org.apache.log4j.PropertyConfigurator;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import java.io.PrintWriter;import java.io.IOException;public class Log4jInit extends HttpServlet { public void init() { String prefix = getServletContext().getRealPath("/"); String file = getInitParameter("log4j-init-file"); // if the log4j-init-file is not set, then no point in trying if(file != null) { PropertyConfigurator.configure(prefix+file); } } public void doGet(HttpServletRequest req, HttpServletResponse res) { }}

Define the following servlet in the web.xml file for your web-application.

 <servlet> <servlet-name>log4j-init</servlet-name> <servlet-class>com.foo.Log4jInit</servlet-class> <init-param> <param-name>log4j-init-file</param-name> <param-value>WEB-INF/classes/log4j.lcf</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>

Writing an initialization servlet is the most flexible way forinitializing log4j. There are no constraints on the code you can placein the init() method of the servlet.

Nested Diagnostic Contexts

Most real-world systems have to deal with multiple clientssimultaneously. In a typical multithreaded implementation of such asystem, different threads will handle different clients. Logging isespecially well suited to trace and debug complex distributedapplications. A common approach to differentiate the logging output ofone client from another is to instantiate a new separate logger foreach client. This promotes the proliferation of loggers andincreases the management overhead of logging.

A lighter technique is to uniquely stamp each log request initiatedfrom the same client interaction. Neil Harrison described this methodin the book "Patterns for Logging Diagnostic Messages," in PatternLanguages of Program Design 3, edited by R. Martin, D. Riehle,and F. Buschmann (Addison-Wesley, 1997).

To uniquely stamp each request, theuser pushes contextual information into the NDC, the abbreviation ofNested Diagnostic Context. The NDC class is shown below.

 public class NDC { // Used when printing the diagnostic public static String get(); // Remove the top of the context from the NDC. public static String pop(); // Add diagnostic context for the current thread. public static void push(String message); // Remove the diagnostic context for this thread. public static void remove(); }

The NDC is managed per thread as a stack of contextualinformation. Note that all methods of the org.apache.log4j.NDCclass are static. Assuming that NDC printing is turned on, every timea log request is made, the appropriate log4j component will includethe entire NDC stack for the current thread in the logoutput. This is done without the intervention of the user, who isresponsible only for placing the correct information in the NDC byusing the push and pop methods at a fewwell-defined points in the code. In contrast, the per-client loggerapproach commands extensive changes in the code.

To illustrate this point, let us take the example of a servletdelivering content to numerous clients. The servlet can build the NDCat the very beginning of the request before executing other code. Thecontextual information can be the client's host name and otherinformation inherent to the request, typically information containedin cookies. Hence, even if the servlet is serving multiple clientssimultaneously, the logs initiated by the same code, i.e. belonging tothe same logger, can still be distinguished because each clientrequest will have a different NDC stack. Contrast this with thecomplexity of passing a freshly instantiated logger to all codeexercised during the client's request.

Nevertheless, some sophisticated applications, such as virtualhosting web servers, must log differently depending on the virtualhost context and also depending on the software component issuing therequest. Recent log4j releases support multiple hierarchy trees. Thisenhancement allows each virtual host to possess its own copy of thelogger hierarchy.

Performance

One of the often-cited arguments against logging is itscomputational cost. This is a legitimate concern as even moderatelysized applications can generate thousands of log requests. Mucheffort was spent measuring and tweaking logging performance. Log4jclaims to be fast and flexible: speed first, flexibility second.

The user should be aware of the following performance issues.

1. Logging performance when logging is turned off.
   

   When logging is turned off entirely or just for a set of levels, the cost of a log request consists of a method invocation plus an integer comparison. On a 233 MHz Pentium II machine this cost is typically in the 5 to 50 nanosecond range.

   However, The method invocation involves the "hidden" cost of parameter construction.

   For example, for some logger cat, writing,

    logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); 

   incurs the cost of constructing the message parameter, i.e. converting both integer i and entry[i] to a String, and concatenating intermediate strings, regardless of whether the message will be logged or not. This cost of parameter construction can be quite high and it depends on the size of the parameters involved.

   To avoid the parameter construction cost write:

    if(logger.isDebugEnabled() { logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); } 

   This will not incur the cost of parameter construction if debugging is disabled. On the other hand, if the logger is debug-enabled, it will incur twice the cost of evaluating whether the logger is enabled or not: once in debugEnabled and once in debug. This is an insignificant overhead because evaluating a logger takes about 1% of the time it takes to actually log.

   In log4j, logging requests are made to instances of the Logger class. Logger is a class and not an interface. This measurably reduces the cost of method invocation at the cost of some flexibility.

   Certain users resort to preprocessing or compile-time techniques to compile out all log statements. This leads to perfect performance efficiency with respect to logging. However, since the resulting application binary does not contain any log statements, logging cannot be turned on for that binary. In my opinion this is a disproportionate price to pay in exchange for a small performance gain.

2. The performance of deciding whether to log or not to log when logging is turned on.
   

   This is essentially the performance of walking the logger hierarchy. When logging is turned on, log4j still needs to compare the level of the log request with the level of the request logger. However, loggers may not have an assigned level; they can inherit them from the logger hierarchy. Thus, before inheriting a level, the logger may need to search its ancestors.

   There has been a serious effort to make this hierarchy walk tobe as fast as possible. For example, child loggers link only totheir existing ancestors. In the BasicConfiguratorexample shown earlier, the logger named com.foo.Bar islinked directly to the root logger, thereby circumventing thenonexistent com or com.foo loggers. Thissignificantly improves the speed of the walk, especially in "sparse"hierarchies.

   The typical cost of walking the hierarchy is typically 3 times slower than when logging is turned off entirely.

3. Actually outputting log messages
   

   This is the cost of formatting the log output and sending it to its target destination. Here again, a serious effort was made to make layouts (formatters) perform as quickly as possible. The same is true for appenders. The typical cost of actually logging is about 100 to 300 microseconds.

   See org.apache.log4.performance.Logging for actual figures.

Although log4j has many features, its first design goal was speed.Some log4j components have been rewritten many times to improveperformance. Nevertheless, contributors frequently come up with newoptimizations. You should be pleased to know that when configured withthe SimpleLayoutperformance tests have shown log4j to log as quickly asSystem.out.println.

Conclusions

Log4j is a popular logging package written in Java. One of itsdistinctive features is the notion of inheritance in loggers. Usinga logger hierarchy it is possible to control which log statementsare output at arbitrary granularity. This helps reduce the volume oflogged output and minimize the cost of logging.

One of the advantages of the log4j API is its manageability. Oncethe log statements have been inserted into the code, they can becontrolled with configuration files. They can be selectively enabledor disabled, and sent to different and multiple output targets inuser-chosen formats. The log4j package is designed so that logstatements can remain in shipped code without incurring a heavyperformance cost.

Acknowledgments

Many thanks to N. Asokan for reviewing the article. He is also one ofthe originators of the logger concept. I am indebted to Nelson Minarfor encouraging me to write this article. He has also made many usefulsuggestions and corrections to this article. Log4j is the result of acollective effort. My special thanks go to all the authors who havecontributed to the project. Without exception, the best features inthe package have all originated in the user community.

Copyright © 1999-2012 Apache Software Foundation. Licensed under the Apache Software License, Version 2.0.

Apache Extras Companion for Apache log4j, Apache log4j, Apache, the Apache feather logo, the Apache Logging Services project logo, the log4j logo, and the Built by Maven logo are trademarks of The Apache Software Foundation. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.