- Tomcat tutorial
- What is Tomcat valve?
- Tomcat security realms
- Log4j project
- Log4j appenders
- Log4j configurators
- How to install Apache & Tomcat server
- Tomcat deployment
- Configure Tomcat
- How to use Tomcat manager
- Jakarta Tomcat server overview
- Jakarta Tomcat server (part 2)
- Persistend sessions
- Embedding Tomcat services
- Find out more about Tomcat architecture
- How to install tomcat on Windows & Linux
Appenders allow logging requests to be printed to multiple output destinations such as consoles, files, NT event loggers, and many others.
The most common way to leverage an Appender is to assign it a Layout and then assign it to a Category.
This is done using a code snippet similar to the following:
log4j.category.chapter11.Log4JApp= DEBUG, console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.layout=org.apache.log4j.SimpleLayout
As you examine the previous snippet, you should ignore the first line. (It is discussed in the following section.)
We need to focus on the second and third lines of this snippet. The second line defines an Appender named console that uses the org.apache.log4j.ConsoleAppender, which does just as it sounds and logs all messages to the application console.
The third line of this snippet assigns the Layout class org.apache.log4j.SimpleLayout to the console Appender. These lines together define an Appender named console that outputs all of its messages in the format defined by the SimpleLayout object to the application console.
In the next section, we close the loop by assigning the Appender to a Category.
Categories are the heart of Log4J. They allow developers to define how and when a log statement should be executed and then assign this definition a case-sensitive name that it can be referenced by. This name is the Category name that can be loaded and used to log messages. An example of this would be a Category that logged all "debug" statements to the Appender defined in the previous section. An example definition of a Category doing just this is contained in the following code snippet:
log4j.category.chapter11.Log4JApp= DEBUG, console
This statement defines a Category named chapter11.Log4JApp that logs all messages with a priority of DEBUG or higher to the console of the running application.
The DEBUG and console values associated with this Category define the priority level of this Category and the name of the Appender to use when logging a message, respectively.
Categories are referenced by name, and so to access the previous Category definition you would call the static Category.getInstance() method with the name of the Category:
static Category cat = Category.getInstance("chapter11.Log4JApp");
This statement creates an instance of a Category that can be used to log messages based on the previous Category definition.
You can now log messages using any of the logging methods described in the next section.
Priorities are assigned to Categories to determine which log messages to actually log.
The set of possible priorities are DEBUG, INFO, WARN, ERROR, and FATAL. If a category is not assigned a priority, it inherits its category from its closest ancestor with an assigned priority.
A Category must contain a Priority level, either explicitly, by naming the Priority in the Category definition, or implicitly, through inheritance.
Messages are logged based upon their priority. This is done using the Category's logging methods: debug(), info(), warn(), error(), and fatal(), which map one-to-one with the defined Priorities described previously.
So, if you wanted to log a message with a priority of DEBUG, you would execute something similar to the following: cat.debug("This is the DEBUG log message!");
This statement logs a message to the Category referenced by cat with Priority level of DEBUG. To determine whether the message is actually logged, the Category must examine its defined Priority.
In this instance, the message is logged because the assigned Category Priority, DEBUG, is less than or equal to the Priority used in the debug() method.
The Priority order is defined as follows:
DEBUG < INFO < WARN < ERROR < FATAL