[Deploying Sakai] Replacing Log4j with Logback

Steve Swinsburg steve.swinsburg at gmail.com
Thu May 30 07:48:25 PDT 2013

I agree with John and think we should just fix the code to use the new
framework rather than mess around with bridges and whatnot. If it is
untouched code then they should be dependency jars - if we have the code we
should modify it as we need to.

This could perhaps be made easier by just using the Lombok annotation on
the various classes to inject the Log initialisation at compile time. I use
this annotation library everywhere I can to reduce boilerplate:



On Fri, May 31, 2013 at 12:28 AM, Seth Theriault <slt at columbia.edu> wrote:

> 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
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20130531/628efa15/attachment.html 

More information about the production mailing list