[Deploying Sakai] Replacing Log4j with Logback

[Seth Theriault]

On Thu, May 30, 2013 at 3:36 AM, John Bush <john.bush at rsmart.com> wrote:
> This sounds reasonable to me.  Three thoughts:
>
> 1. why not just fix the 3 imsglobal files and not deal with the JUL
> thing.  Looks like a 10 minute affair to fix up that stuff

I actually asked Chuck Severance about these files. He said they are
untouched IMS code that was written to the lowest common denominator
(I'm paraphrasing here) for any Java version.

> 2.  If the migrator and all the code migration turns out to be
> problemmatic could we fall back to just including jcl-over-slf4j.jar
> instead of commons-logging.jar as a step forward ? We'd have to still
> deal with LogConfigurationManager, but don't imagine that is terribly
> hard, which gets me to next point.

Yes,we probably could but we might still need to make a few manual changes.

My original experiment -- done long ago -- was doing exactly this. I
created a new LogConfigurationManager implementation for Logback,
dropped in the correct bridge libraries for Log4j and JCL, and fired
up Sakai. It sort of worked, but croaked in the expected places in
Log4J (direct calls to appenders, calls to PropertyConfigurator,
etc.). We would need to clean-up those cases manually.

We also have a lot of code calling Log4j directly (1651 files based on
a rudimentary grep) compared to JCL (126 files).

> 3.  Would removing the ability to set log levels from sakai.properties
> and moving it somewhere else entirely be such a bad idea.  It's not
> runtime modifiable from there now.  Plus you can't control very much,
> only set log level for packages, nothing fancy.

The sakai.properties functionality demystifies some of the intricacies
of log4j configuration, which is good. I think it would be interesting
to see if Logback's configuration file auto-reload-on-changes:

http://logback.qos.ch/manual/configuration.html#autoScan

could really work for Sakai and how we could demystify some of that
with a better interface.

Seth