Log4j2 Tutorial 3 – Setup Console Appender Using XML Configuration File

Introduction

In the previous post, we have learned Creating Log4j2 Maven Project With Default Configuration File. When we do not add any configuration file, Log4j2 provides default configuration and prints error and fatal logs on the standard console.

In this post, we will add a user-defined XML configuration file.

Did you know that I have started a YouTube channel as well and I need your support to make it successful. Please do watch content then comment, like, share, and obviously subscribe.

Required Dependencies

Always use the latest version of dependencies. I am using the below version of Log4j2 which is the latest at the time of writing this post.



    org.apache.logging.log4j
    log4j-core
    2.14.1

What is a Configuration File in Log4j2?

A configuration file in Log4j2 helps us to set up where to log, how to log, and what to log. A configuration file is used in Log4j2 to specify appenders and loggers mainly. This file is written in XML, JSON, YAML, or properties format.

A very simple XML configuration file (default provided by Log4j2 – You can not find that in a project) will look like below:-

There are two major components in any configuration file i.e. XML, JSON, properties or YAML.

Appenders – Where to print logs. We can have multiple appenders.
Loggers – From where to log and what to log

In the above example, you can see that we are using “Console” tag within “Appenders” tag. It represents that I want to print logs in the console. We can have multiple appenders which we will see later. Inside “Console” tag we have another tag “PatternLayout” which defines the pattern of printing logs. We have seen that in a previous post.

Automatic Configuration

Log4j2 follows a search order to look for the configuration files and I think they have explained best on their official website. Below is a copied content from there.

Log4j has the ability to automatically configure itself during initialization. When Log4j starts it will locate all the ConfigurationFactory plugins and arrange them in weighted order from highest to lowest. As delivered, Log4j contains four ConfigurationFactory implementations: one for JSON, one for YAML, one for properties, and one for XML.

Log4j will inspect the “log4j2.configurationFile” system property and, if set, will attempt to load the configuration using the ConfigurationFactory that matches the file extension. Note that this is not restricted to a location on the local file system and may contain a URL.
If no system property is set the properties ConfigurationFactory will look for log4j2-test.properties in the classpath.
If no such file is found the YAML ConfigurationFactory will look for log4j2-test.yaml or log4j2-test.yml in the classpath.
If no such file is found the JSON ConfigurationFactory will look for log4j2-test.json or log4j2-test.jsn in the classpath.
If no such file is found the XML ConfigurationFactory will look for log4j2-test.xml in the classpath.
If a test file cannot be located the properties ConfigurationFactory will look for log4j2.properties on the classpath.
If a properties file cannot be located the YAML ConfigurationFactory will look for log4j2.yaml or log4j2.yml on the classpath.
If a YAML file cannot be located the JSON ConfigurationFactory will look for log4j2.json or log4j2.jsn on the classpath.
If a JSON file cannot be located the XML ConfigurationFactory will try to locate log4j2.xml on the classpath.
If no configuration file could be located the DefaultConfiguration will be used. This will cause logging output to go to the console.

Placing configuration file in the project

We know now that Log4j2 will look for a configuration file in the classpath of projects. For this we should keep a configuration file under the resource folder. We will make changes in the above XML file to print all levels of logs in the console. Under the “Loggers” tag we have another tag called “Root”. Root Logger is the topmost element in every Logger Hierarchy. This “Root” tag contains a property called “level”. We can provide it to any level and we know what are logs will be eligible for printing. I have changed level to “trace” so that all levels will be printed.

Now run the same class from the previous post. There is no need to change anything in class.

Example Program

package appCode;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class ModuleA {
	
	// Creating a logger
	private static Logger logger = LogManager.getLogger();

	// Log messages
	public static void main(String[] args) {
		
		logger.debug("It is a debug logger.");
		logger.error("It is an error logger.");
		logger.fatal("It is a fatal logger.");
		logger.info("It is a info logger.");
		logger.trace("It is a trace logger.");
		logger.warn("It is a warn logger.");

	}
}

Output

14:25:40.153 [main] DEBUG appCode.ModuleA - It is a debug logger.
14:25:40.172 [main] ERROR appCode.ModuleA - It is an error logger.
14:25:40.172 [main] FATAL appCode.ModuleA - It is a fatal logger.
14:25:40.172 [main] INFO  appCode.ModuleA - It is a info logger.
14:25:40.172 [main] TRACE appCode.ModuleA - It is a trace logger.
14:25:40.172 [main] WARN  appCode.ModuleA - It is a warn logger.

You can also change the Pattern layout and there are many patterns available which are given here.

GitHub Link to clone project

Log4j2 Example Codes

You can subscribe to my YouTube channel RetargetCommon to learn from video tutorials.

If you have any doubt, feel free to comment below.
If you like my posts, please like, comment, share and subscribe.
#ThanksForReading
#HappyLearning

Find all Selenium related posts here, all API manual and automation related posts here, and find frequently asked Java Programs here.

Many other topics you can navigate through the menu.