Mybatis源码-日志模块(1)

  Mybatis的日志模块的作用是为了让mybatis在项目中被使用的时候，无论什么情况都能有一种日志实现让mybatis可以正常的打日志。所以mybatis不能用单一的实现方式去打印日志。
不能像我们平常一样用slf4j的LogFactory.getLogger(XXXX)一样去用日志。因为它可能在没有Slf4j的项目里被使用。难道就不打日志了么？

  那mybatis怎么办呢？他就在各种输出手段的外面再包一层统一的接口门面。然后哪个可以用就用哪个。也就是设计模式中的“适配器模式”。通过LogFactory和Log统一封装底层不同实现的差异。在mybatis自己的代码中，记录日志的常规用法就是LogFactory.getLog(XXX.class)

这里面的主要代码集中实现在LogFactory中。对照注释阅读。

public final class LogFactory {

  /**
   * Marker to be used by logging implementations that support markers.
   */
  public static final String MARKER = "MYBATIS";

  private static Constructor<? extends Log> logConstructor;

  static {
    /**
     * 依次去尝试设置LogFactory会用哪一种Log实现去做日志。
     * 第一个成功的会塞入logConstructor，用于后面创建mybatis的通用日志接口Logger
     * 最优先的是slf4j。从上到下一次排列
     *
     * 这里有一个问题是为什么每一种useXXX方法都是同步的呢？他们明明就在同一个static块中被依次调用。
     * 后来仔细一想，是因为这些方法也可以在LogFactory的Class被初始化加载之后，在不用的地方被不同的线程调用。
     * 从而动态改变Log的具体实现者，如果这些方法不是synchronized的话，不同的线程对logConstructor就会出现可见性问题。
     * 类似于单例懒加载双重检查锁。
     */
    tryImplementation(LogFactory::useSlf4jLogging);
    tryImplementation(LogFactory::useCommonsLogging);
    tryImplementation(LogFactory::useLog4J2Logging);
    tryImplementation(LogFactory::useLog4JLogging);
    tryImplementation(LogFactory::useJdkLogging);
    tryImplementation(LogFactory::useNoLogging);
  }

  private LogFactory() {
    // disable construction
  }

  public static Log getLog(Class<?> aClass) {
    return getLog(aClass.getName());
  }

  public static Log getLog(String logger) {
    try {
      return logConstructor.newInstance(logger);
    } catch (Throwable t) {
      throw new LogException("Error creating logger for logger " + logger + ".  Cause: " + t, t);
    }
  }

  public static synchronized void useCustomLogging(Class<? extends Log> clazz) {
    setImplementation(clazz);
  }

  public static synchronized void useSlf4jLogging() {
    setImplementation(org.apache.ibatis.logging.slf4j.Slf4jImpl.class);
  }
  //····省略一堆userXXLogging方法……

  //这里的逻辑一种是一种装载缓存内容的典型判断，没有就尝试去装载logConstructor
  private static void tryImplementation(Runnable runnable) {
    if (logConstructor == null) {
      try {
        runnable.run();
      } catch (Throwable t) {
        // ignore
      }
    }
  }
  //这里尝试传入的是实现了ibatis的Log适配器接口的实现类
  private static void setImplementation(Class<? extends Log> implClass) {
    try {
      //这些实现类都有一个string参数的构造器，用于传入logger的名字，
      //不过这一点并不是从语法上限制死的。而是mybatis对每一个实现都提供了这样的constructor
      Constructor<? extends Log> candidate = implClass.getConstructor(String.class);
      //用mybatis的LogFactory的名字创建一个mybatis的log接口，具体的实现由被适配的具体实现决定
      Log log = candidate.newInstance(LogFactory.class.getName());
      //马上就用了，打印的第一句就是，表明用了什么日志适配器实现
      if (log.isDebugEnabled()) {
        log.debug("Logging initialized using '" + implClass + "' adapter.");
      }
      //Log适配器的构造器缓存下来，用于后面创建其他日志
      logConstructor = candidate;
      //所以这个方法的核心作用就是，抽取我们的真正的日志适配器实现的constructor缓存起来，用于后面创建log
    } catch (Throwable t) {
      //注意这个方法其实会经常抛错的。因为要用底层的实现的前提是引入了这个实现的包。并且能用。
      // 当不成功的时候，通常就是缺了实现类。比如第一个的Slf4j的logg实现，如果没有slff4j的jar，自然就失败了。
      //所以在外面tryImplementation这个方法会抓住我们的初始化异常。并忽略它。设置失败就算咯~尝试其他的。
      throw new LogException("Error setting Log implementation.  Cause: " + t, t);
    }
  }

}