Functionality overview
Logging is typically broken into three major pieces: the Logger, the Formatter and the Appender (or Handler). * The Logger is responsible for capturing the message to be logged along with certain metadata and passing it to the logging framework. * After receiving the message, the framework calls the Formatter with the message which formats it for output. * The framework then hands the formatted message to the appropriate Appender/Handler for disposition. This might include output to a console display, writing to disk, appending to a database, or generating an email. Simpler logging frameworks, likLogger
A Logger is an object that allows the application to log without regard to where the output is sent/stored. The application logs a message by passing an object or an object and an exception with an optional severity level to the logger object under a given name/identifier.Name
A logger has a name. The name is usually structured hierarchically, with periods (.) separating the levels. A common scheme is to use the name of the class or package that is doing the logging. Both Log4j and the Java loggingcom.sun.some.UsefulClass
". The handler can be defined for any of the following:
* com
* com.sun
* com.sun.some
* com.sun.some.UsefulClass
As long as there is a handler defined somewhere in this stack, logging may occur. For example a message logged to the com.sun.some.UsefulClass
logger, may get written by the com.sun
handler. Typically there is a global handler that receives and processes messages generated by any logger.
Severity level
The message is logged at a certain level. Common level names are copied froFilters
Filters cause a log event to be ignored or logged. The most commonly used filter is the logging level documented in the previous section. Logging frameworks such as Log4j 2 and SLF4J also provide Markers, which when attached to a log event can also be used for filtering. Filters can also be used to accept or deny log events based on exceptions being thrown, data within the log message, data in a ThreadLocal that is exposed through the logging API, or a variety of other methods.Formatters, Layouts or renderers
A Formatter is an object that formats a given object. Mostly this consists of taking the binary object and converting it to a string representation. Each framework defines a default output format that can be overridden if desired.Appenders or handlers
Appenders listen for messages at or above a specified minimum severity level. The Appender takes the message it is passed and posts it appropriately. Message dispositions include: * display on the console * write to a file or syslog * append to a database table * distribute via Java Messaging Services * send via email * write to a socket * discard to the "bit-bucket" (/dev/null)Feature comparison
Considerations
JCL and Log4j are very common simply because they have been around for so long and were the only choices for a long time. The flexibility of slf4j (using Logback underneath) has made it a popular choice. SLF4J is a set of logging wrappers (or shims) that allow it to imitate any of the other frameworks. Thus multiple third-party libraries can be incorporated into an application, regardless of the logging framework each has chosen to use. However all logging output is generated in a standard way, typically via Logback. Log4j 2 provides both an API and an implementation. The API can be routed to other logging implementations equivalent to how SLF4J works. Unlike SLF4J, the Log4j 2 API logs Message objects instead of Strings for extra flexibility and also supports Java Lambda expressions. JCL isn't really a logging framework, but a wrapper for one. As such, it requires a logging framework underneath it, although it can default to using its ownSimpleLog
logger.
JCL, SLF4J and the Log4j 2 API are useful when developing reusable libraries which need to write to whichever underlying logging system is being used by the application. This also provides flexibility in heterogeneous environments where the logging framework is likely to change, although in most cases, once a logging framework has been chosen, there is little need to change it over the life of the project. SLF4J and Log4j 2 benefit from being newer and build on the lessons learned from older frameworks. Moreover JCL has known problems with class-loaders when determining what logging library it should wrap which has now replaced JCL.
The Java Logging API is provided with Java. Although the API is technically separate from the default implementation provided with Java, replacing it with an alternate implementation can be challenging so many developers confuse this implementation with the Java Logging API. Configuration is by external files only which is not easily changed on the fly (other frameworks support programmatic configuration). The default implementation only provides a few Handlers and Formatters which means most users will have to write their own.See also
*References
External links