[Deploying Sakai] Replacing Log4j with Logback

Seth Theriault slt at columbia.edu
Wed May 29 21:09:09 PDT 2013


More than a year ago, I mentioned that I was looking at replacing the
current Apache Commons Logging + Log4j framework with Logback:


I have decided to move forward with this and am now proposing a
wholesale replacement of the current framework. I am looking for
others to join me in this endeavor, especially since it affects the
entire codebase.

As you may know, Logback is a successor to Log4j and relies on SLF4J,
a widely used logging abstraction layer, that we already use in some


SLF4J includes API bridges to allow use of other "legacy" frameworks with it:


and a migrator tool to change code:


The main reason I think we should do this to bring Sakai's logging
into the modern age. The author of logback (who also created Log4j)
has numerous other reasons:


All of them apply to Sakai, as they do to many other projects.

It's easy to give reasons to change to a new framework or to run code
through an automated migrator, but the actual work usually surfaces
problems. One that we will have to tackle is Sakai's
LogConfigurationManager, of which Log4j is the only implementation. We
clearly want to preserve the current ability to set log levels via
sakai.properties, although this may be less important if we can adjust
Logback's settings on the fly.

Another is the licensing. While SLF4J is released under the Apache
license, Logback is dual-licensed under the LGPL and Eclipse Public
License. I am informed that the latter is probably OK if we distribute
Logback without making modifications to the binaries.

We may also run into issues with Tomcat because of the changes that
were made to how it handles its own logging:


I am not 100% sure that this will be problematic, but Tomcat is
sometimes tempermental about these things.

In addition, there is the question of the 7 files in sakai-trunk-all
that use java.util.logging:


My plan would be to use the JUL-to-SLF4J API bridge for the 3
org.imsglobal classes and convert the others to use Logback. This
should avoid most of the risk associated with bridging the JUL as
detailed on the API bridge Web page.

Finally, there is the question of Log4j 2.x instead of Logback:


This new release is still in beta and would also require significant
re-coding work to adopt. I am not sure we save ourselves any work by
adopting Log4j 2.x over Logback, which has been in use for quite a

Comments, counterproposals, and questions are welcomed and encouraged.
I will be in San Diego next week, so feel free to talk to me there as


More information about the production mailing list