A conceptula model for understanding Java logging frameworks presented at the South Africa Oracle Java Developer Conference, May 2012

1. Java Logging Frameworks
Demystified
By
Jumping Bean
21 May 2012

2. 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

3. Jozi JUG

4. Jozi JUG

Meet once a month in Johannesburg,

Talk

Beer

Pizza

All FREE!

Where to find us?
− Meetup
− Facebook
− Web Site

5. Why Log?

Needed during development to identify errors,

Needed during production for troubleshooting,

6. 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

7. 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?

8. 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,

9. 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

10. 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

11. 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.

12. Other Java Logging Frameworks

Even more logging frameworks, over 20!

http://java-source.net/open-source/logging

13. What's missing?
A conceptual model

14. Conceptual Model

Logging Entities

Interaction between entities

Each framework has variations on the model

15. Conceptual Model

Logging Entities

Interaction between entities

16. 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

17. Log Manager

Global object to access logging system,

Used to create or retrieve
− Loggers
− Handlers
− Filters
− Appenders
− etc

18. 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

19. Severity/Level

Classification of the Log Message.

Organised in a hierarchy of severity

Lower level include higher level messages

20. 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

21. 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

22. 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

23. 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

24. 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

25. Sequence Diagram

26. 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,

29. Configuration

Configuration can be done at compile time in
code

At runtime with configuration files

At runtime via JMX

30. 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

31. 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

32. Java Logging Frameworks
The End