[LOG4J2-519] Custom/Extended Loggers

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0-rc1
• Fix Version/s: 2.0
• Component/s: API
• Assignee: Remko Popma
• Reporter: Remko Popma
• Created: 28/Jan/14 13:05
• Updated: 17/Jul/14 15:16
• Resolved: 11/Jul/14 16:22

Description

Please try out the attached Generate.java tool that provides the functionality described below and give feedback if you notice any issues.

Extending the Logger interface
LOG4J2-41 added support for custom log Levels. Users can now log messages at the new custom level by passing the custom level to the Logger.log() method:

final Logger logger = LogManager.getLogger();
final Level VERBOSE = Level.forName("VERBOSE", 550);

logger.log(VERBOSE, "a verbose message");
logger.log(VERBOSE, "another message");

However, custom levels are not as easy to use as the built-in levels: one needs to call the generic log() method and pass a Level parameter. Built-in levels on the other hand have a set of convenience methods on the Logger interface. For example, the Logger interface has 14 debug methods that support the DEBUG level:

debug(Marker, Message)
debug(Marker, Message, Throwable)
debug(Marker, Object)
debug(Marker, Object, Throwable)
debug(Marker, String)
debug(Marker, String, Object...)
debug(Marker, String, Throwable)
debug(Message)
debug(Message, Throwable)
debug(Object)
debug(Object, Throwable)
debug(String)
debug(String, Object...)
debug(String, Throwable)

Similar method sets exist for the other built-in levels.

Several people have expressed the desire to have the same ease of use with custom levels, so after declaring a custom VERBOSE level, we would like to be able to use code like this:

logger.verbose("a verbose message"); // no need to pass the VERBOSE level as a parameter
logger.verbose("another message");

Customizing the Logger interface
In the above use case, convenience methods were added to the Logger interface, in addition to the existing trace(), debug(), info(), ... methods for the built-in log levels.

There is another use case, Domain Specific Language loggers, where we want to replace the existing trace(), debug(), info(), ... methods with all-custom methods.

For example, for medical devices we could have only critical(), warning(), and advisory() methods. Another example could be a game that has only defcon1(), defcon2(), and defcon3() levels.

Finally, if it were possible to hide existing log levels, users could customize the Logger interface to match their requirements. Some people may not want to have a FATAL or a TRACE level, for example. They would like to be able to create a custom Logger that only has debug(), info(), warn() and error() methods.

Proposal: Generate source code for a Logger wrapper
Common log4j usage is to get an instance of the Logger interface from the LogManager and call the methods on this interface. This makes it hard to achieve the above customization; especially taking away existing methods is not possible.

An alternative is for the user to create a wrapper class that exposes only the convenience methods for the desired log levels. When extending the Logger API (adding methods), this wrapper class could subclass org.apache.logging.log4j.spi.AbstractLoggerWrapper. When customizing the Logger API (removing built-in methods), the wrapper class would simply not extend AbstractLoggerWrapper, so the only public methods would be the methods for the custom log levels.

As the custom log Levels are not known in advance, Log4J cannot provide pre-built wrapper classes for these custom log Levels. However, we don't want to ask the users to hand-code such a wrapper class: this is cumbersome and error-prone: there are 14 methods for each built-in level. To provide comparable functionality for custom log Levels one would need to provide 14 methods for each custom log Level.

The proposal is to solve this by providing a tool that generates the source code for a wrapper class. The user can specify:

• the fully qualified name of the class to generate
• the list of custom levels to support and their intLevel relative strength
• whether to extend Logger (and keep the existing built-in methods) or have only methods for the custom log levels

and the tool generates the source code for the wrapper class that has exactly the required methods. Users would include this source code in the project where they want to use custom log levels.

Note that no Log4J API changes are required to support this functionality.

Users would create instances of the wrapper by calling a factory method on the wrapper class, instead of calling the LogManager.getLogger() methods.

For example, instead of writing:

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

final Logger logger = LogManager.getLogger(MyClass.class); // standard log4j logger
final Level VERBOSE = Level.forName("VERBOSE", 550);
logger.log(VERBOSE, "a verbose message");

users would instead write:

// MyLogger is a generated customized logger wrapper
import com.mycompany.myproject.MyLogger;

final MyLogger logger = MyLogger.create(MyClass.class);
logger.verbose("a verbose message");

Creating an extended or customized Logger is as easy as creating a standard Logger (one line of code). Extended Loggers are drop-in replacements for standard Loggers - they only add more convenience methods.

Issue Links

• depends upon: LOG4J2-41 Extensible Log Level
• is superceded by: LOG4J2-710 Documentation for Custom Levels and Custom Loggers