Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-30828

Normalize Sakai logging



    • Type: Bug
    • Status: CLOSED
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 11.0
    • Fix Version/s: 11.2, 12.0
    • Component/s: Global
    • Labels:
    • 11 status:


      Sakai has a mix of logging libraries, mostly

      • commons-logging (JCL)
      • log4j
      • slf4j
      • System.out
      • tomcat-juli

      The catalina.out log is mess because of all the different logging facilities and their different formats.

      SLF4J was a good start as it is similar to JCL which abstracts the logging implementation so that someone could easily switch to a different logging implementation. The most notable reason why slf4j is a better choice is because of class loader issues. EntityBroker had much of its logging (JCL) removed due to class loader issues http://articles.qos.ch/classloader.html

      As a way forward for new code using slf4j annotation:

       public class LogExample {

      will generate:

      public class LogExample {
           private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class);

      or a more traditional approach:

      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      public class LogExample {
           private static final Logger log = LoggerFactory.getLogger(LogExample.class);

      Whether to use a static or instance member of the Logger are both fine see http://www.slf4j.org/faq.html#declared_static

      We will always need JCL support due to many libraries requiring JCL like spring. Therefore using jcl-over-slf4j is needed for those libraries.

      Lastly I am proposing a change the sakai appender's pattern to match the logger output of tomcat-juli so that the log4j and tomcat-juli look the same giving a consistent logging experience.

      Lastly its worth noting that external libraries that output System.out will continue to do so like genericdao and rsf. These libraries are deprecated and should be avoided in the future.

      Please see this link for examples of performance and logging http://www.slf4j.org/faq.html#logging_performance

      For example: (1st line is traditional logging, 2nd line is updated for slf4j)

      if (logger.isDebugEnabled()) logger.debug("Log parameters One: "+one+", and Two:"+two);
      logger.debug("Log parameters One: {}, and Two: {}", one, two);

      This doesn't mean that older method is not useful in certain situations but it does simplify the logging. Also another advantage is null params are printed as the word "null" in the replacement, instead of throwing NPE.

        Gliffy Diagrams



              Issue Links



                  ern Earle R Nietzel
                  ern Earle R Nietzel
                  1 Vote for this issue
                  6 Start watching this issue



                      Git Integration