Java Logging Frameworks Demystified

By Jumping Bean

21 May 2012

Who Am I?

Mark Clarke – Java Developer Working for Jumping Bean, an open source

solutions integration company Working with Java & open source

technologies since 2001 Co-founder of Jozi JUG

Jozi JUG

Jozi JUG

Meet once a month in Johannesburg, Talk Beer Pizza All FREE! Where to find us?

− Meetup− Facebook− Web Site

Why Log?

Needed during development to identify errors, Needed during production for troubleshooting,

Requirements for a Logging Framework

Logging should be easy for the developer to use,

Logging should be flexible, Logging setup/config should be easy,

especially for system administrators Configuration should be done at runtime, Framework should free you up to concentrate

on the business/application logic

Reality of Logging Framework

BUT− Logging frameworks are difficult to

understand,− Logging frameworks are difficult to configure− Lots of heat but not much light when

searching the Interwebs Why?

− Competing frameworks, Part of Java community culture

− Over engineered?

Why So Complex?

Why are logging frameworks so complex?− Filtering of log messages to extract

messages that meet system admin defined criteria,

− Writing of a single log message to multiple destination,

− Formatting log messages for different log back-ends such as text files, databases, email etc.

− Ensuring logging has minimal impact on performance,

Why So Complex?

− Integrating 3r party libraries with their own logging requirements,

− Allowing for the runtime selection of logging frameworks,

− Allowing for runtime configuration of the selected logging framework,

− Applications are distributed

Well Known Java Logging Frameworks

Log4j - The progenitor of all logging frameworks

java.util.logging- The usurper. Attempted to add log4j to the Java JDK & improve on it.

Jakarta Commons Logging - The failed abstractor. attempted to allow the underlying logging framework to be determined by the system administrator deploying the application

Well Known Java Logging Frameworks

Simple Logging Façade for Java -The great abstractor. Some would call slf4j the saviour of Java logging. It is largely successful at abstracting away the underlying logging framework, allowing for it to be change at runtime with relative ease.

Logback -The return of the jedi - This is the successor to the great progenitor log4j. Looks promising.

Other Java Logging Frameworks

Even more logging frameworks, over 20!

http://java-source.net/open-source/logging

What's missing?

A conceptual model

Conceptual Model

Logging Entities Interaction between entities Each framework has variations on the model

Conceptual Model

Logging Entities Interaction between entities

Logging Entities

Entity Description

Log Manager Access point to logging system

Log Message/Log Entry The log message

Severity/Level A ranking of the log messages, also used as a filter criteria

Logger A processing unit for the log message

Appenders/Handlers A target to send the log message to

Filters Criteria used to filter message

Formatters/Renderers/Layouts Formatting of the log message for its handler/appender

Log Manager

Global object to access logging system, Used to create or retrieve

− Loggers− Handlers− Filters− Appenders− etc

Log Message

The application message you wish to log. Can do things like:

− Replace parameters at logging time,− Convert objects into string representations

etc. Log messages have a severity attached to

them Log messages are sent to a single Logger

Severity/Level

Classification of the Log Message. Organised in a hierarchy of severity Lower level include higher level messages

Logger

A logger is conceptually like a message queue A logger “processes” a log message Loggers are identified by string names Loggers are in a hierarchy determined

identifier. Logger hierarchy set by “.” in logger identifier

Logger

Every Logger has a parent, Root Logger is top of the logger hierarchy and

always exists Loggers are source of complexity as Log

messages “bubble up” the hierarchy Loggers can have severity levels to filter

incoming log messages

Appenders/Handlers

Represents a destination for a log method once it has been accepted by a Logger,

Loggers can have more than one appender An appender can belong to more than one

logger Appenders can be anything

− Database− Text file− Console− Email

Filters

A filter is a criteria against which incoming log messages are compared to be processed or discarded

Filters can be on Loggers in some cases Filters can be on appenders, A filter can be attached to more than one

appender/logger

Formatters/Layouts

These entities format a log message for their assigned appenders,

Add information to the log message like timestamp, class information etc

Formatters/Layouts usually depend on the type of the appender

Sequence Diagram

How Log Messages Bubble Up

Log messages received by a Logger and passed up the Logger hierarchy

The exact flow varies from framework to framework

Source of much confusion− Unwanted log messages in appenders,

Configuration

Configuration can be done at compile time in code

At runtime with configuration files At runtime via JMX

Meta Loggers

Frameworks to abstract away Logging frameworks,

Allow for run time changing of logging frameworks,

Apache Commons Logging – not used due to architectural issues,

Sl4j – Best meta logging framework

Meta Loggers

SL4J allows for code to be written without concern for underlying framework

− Change deployed jars to target different frameworks

SL4J – allows for bridging of disparate logging frameworks in 3rd party libraries used in your application

Java Logging Frameworks

The End