Learn about the Architecture of log4j framework

In the last article, we discussed the log4j logging mechanism overview, features and its installation. In this article, we are going to discuss the architecture of the Log4j API or framework in detail.

Architecture of log4j framework
The log4j API obeys a layered architecture in which each layer provides different objects to achieve different tasks. This layered architecture supports a very flexible and easily extensible design. The log4j framework has the following two types of objects.

• Core Objects: – These objects are known as the required objects of the log4j framework. Therefore, these objects are always needed in order to use and work on the framework. Core objects are further categorized into the following objects.
1. Logger Object  It is the topmost level layer of the log4j framework. It delivers the Logger object which is responsible for capturing the logging information and storing the information into a namespace hierarchy.
2. Layout Object  It is another important sub layer of the Core Object in the log4j framework which delivers layout objects. Layout objects are responsible for formatting the logging information into different layouts or styles. The layer is capable of extending its support to the appender objects in order to publish the logging information into a human-readable format which can be reusable.
3. Appender Object  It is a lower-level layer of the log4j framework. It delivers the Appender objects which is responsible for publishing the logging information to the several desired destinations such as a plain file on a hard disk, a database (i.e. Oracle, MySQL, etc.), and a log management system (LMS), a console, UNIX filesystem, etc.

Inside the configuration file i.e. log4j.properties file, you can add the appender objects to a Logger when you include the setting in the configuration file as shown below.

# Adding appender object to a logger 
log4j.logger. [logger-name]=level, appender1,appender2.. appender (n)

From the above syntax, it is clear that you can add multiple Appender objects to a logger by separating them through commas. Each of the added Appender is capable of printing the logging information to the separate destinations as described before. Alternatively, you can add the appender object to a logger with in the application code by using the below syntax.

public void addAppender (Appender appender);

• Support Objects: – These are the optional objects of log4j framework which supports the core objects in order to achieve the additional tasks which may be significant otherwise. Support objects are further classified into the following objects.
1. Level Object  As the name suggests, the level object is used to define the priority level of any logging information. The log4j logging framework has the following eight levels option available in the framework.

There is a very simple rule of thumb for the Log4j debug level. Any log request via log4j logging mechanism that has a level ‘m’ and a logger is defined at the level ‘n’ will be enabled only if the priority of m >= n. In the log4j framework, the following is order of the levels.
ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF.
Inside the configuration file i.e. log4j.properties file, you can set up the custom log level as shown below. All you have to do is choose any one level out of ‘ALL / DEBUG / INFO / WARN / ERROR / FATAL / OFF’ and define it in the log4j.properties file.

# Define the root logger with appender APP
log4j.rootLogger=ALL / DEBUG / INFO / WARN / ERROR / FATAL / OFF, stdout, APP

2. Filter Object  As the name suggests, the Filter objects is capable of analyzing the logging information beyond level matching. It is also helpful in deciding whether the logging requests should be controlled by a particular Appender or to be completely ignored.
3. ObjectRenderer  The Layout objects use the ObjectRenderer objects during the preparation of the final logging information. It is devoted in providing a String representation of different objects which are delivered to the logging framework.
4. LogManager  As the name suggests, the LogManager object manages the logging framework. It is responsible for reading the initial configuration parameters present in a configuration file or configuration class.
Conclusion: –
In this article, we discussed the log4j framework architecture and the significance of the associated objects present in the log4j framework.