mybatis log模块
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);
}
}
}
