Let’s start with a scenario.
Suppose you are developing an E-commerce application. There will be many modules but just to make it simple let’s suppose you have three modules to develop – searchProduct, calculateValue, and payment. A user will search for a product and add it to the cart. Then cart value will be calculated and the user will be navigated to the payment page. We have a simple flow here.
Data will be moved across modules. While developing you must have to add some standard print commands so that you could track the flow. For example – items are searched correctly, desired items are added to the cart, total payable amount, etc. These standard print statements help you to analyze the code flow and catch if there is any unexpected result or break in the flow. In short a kind of log, it is. These logs will be very important for development, testing, and finding the place of occurrence of a problem later.
The use of standard print statements is not a good way of logging. It will be really difficult to track these print statements in a pool of extra logs coming from other sources (Maven, Gradle, libraries, etc). You may also want to store logs in an external file or keep track of old logs then it may not be easy. The standard print statements will not help much in a production environment.
There are multiple logging libraries are available in Java. You can use Java Logging APIs or Apache Log4j2.
It does not matter if you are a developer or an automation tester you must need to use Logger in your framework and test scripts. In this post, we will learn about Apache Log4j2 Java library.
Apache Log4j is a Java-based logging framework. It has 2 versions – Log4j 1 and Log4j2. Log4j2 is an upgraded version of Log4j 1. We should always use the latest version as it provides more features and bug fixes.
To use Log4j2 in your framework, you just need to add the below libraries:-
log4j-api-.jar log4j-core-.jar
We can configure Log4j2 with our application using a configuration file written in XML, JSON, YAML, or properties format. We can do it programmatically as well but let’s focus on configuring using configuration files as of now. Log4j has the ability to automatically configure itself during initialization. It has an order to look for the configuration file in the application. Log4j will provide a default configuration if it cannot locate a configuration file.
Log levels are a mechanism to categorise logs. Levels used for identifying the severity of an event. We can easily configure levels to specify which log details we want to see. Log4j provides below levels:-
- ALL – To log all events.
- DEBUG – A general debugging event.
- ERROR – An error in the application, possibly recoverable.
- FATAL – A severe error that will prevent the application from continuing.
- INFO – An event for informational purposes.
- TRACE – A fine-grained debug message, typically capturing the flow through the application.
- WARN – An event that might possibly lead to an error.
- OFF – No events will be logged.
Log4j follows order as below:-
ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL
If we mention log level as INFO then all INFO, WARN, ERROR and FATAL events will be logged. If we mention log level as WARN then all WARN, ERROR and FATAL events will be logged. In simple terms, all the levels below the specified level including the specified level will be considered.
We can specify destinations to keep event logs. We may want to print those logs in the console or any external file. Appenders usually are only responsible for writing the event data to the target destination. We may use multiple appenders.
In some upcoming posts, we will learn Log4j2 with some examples.
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