Mybatis设计了自己的“日志系统”
在查看mybatis源码时，发现mybatis源码中使用的log日志，是它自己定义的。比如ResultMap$Builder类中定义log 的代码是这样的：
import org.apache.ibatis.logging.Log;
import org.apache.ibatis.logging.LogFactory;
// 定义log
private static final Log log = LogFactory.getLog(Builder.class);
可见无论是LogFactory， 还是具体的Log，都是mybatis自己定义的类。这似乎与我们平时项目开发不太一样，通常我们的做法是依赖某个第三方的日志框架，然后使用框架提供的API。所以问题来了，mybatis为什么要这么做，难道是为了彰显自己独特吗
Mybatis为啥自定义日志类
要回答这个问题首先得搞清楚mybatis日志类的工作逻辑是什么，根据源码可以看出，mybatis的日志类有点像是我们平时使用的充电接口转换器，它在框架内部统一使用自定义的日志类，但是实际的工作，却是交给它能够找到某个具体日志框架，具体的在后面说。
mybatis并没有真正去实现一套日志处理逻辑，它只是封装了一个中间层，与普通的业务系统相比，他没有强依赖某个具体的日志处理框架，它可以按预设的顺序依次查看类路径下是否有某个日志框架，然后选择其来作为自身日志的实现。
因为mybatis作为一个底层的工具库，它的目标是被业务系统使用，如果它再依赖一个第三方的日志库，就会导致下游的业务系统也必须依赖该第三方日志库，那如果下游业务系统出于某些方面考虑使用了以外一套日志库，这样会导致下游系统同时依赖多个日志库，这必然对下游业务系统来说是不友好的。 所以mybatis创建了一个中间层，可以根据下游业务系统采用的日志框架，来动态的选择自身使用的日志库。
Mybatis是如何自定义日志类的
- 首先定义一个日志类接口Log
package org.apache.ibatis.logging;
public interface Log {
boolean isDebugEnabled();
boolean isTraceEnabled();
void error(String s, Throwable e);
...
}
- 然后定义一个用于获取Log的工厂类LogFactory
package org.apache.ibatis.logging;
import java.lang.reflect.Constructor;
/**
* @author Clinton Begin
* @author Eduardo Macarron
*/
public final class LogFactory {
// 某个日志实现类的构造器实例
private static Constructor<? extends Log> logConstructor;
// 使用静态方法，来选择具体使用的日志库，逻辑就是判断类路径下是否有该日志库
static {
tryImplementation(LogFactory::useSlf4jLogging);
tryImplementation(LogFactory::useCommonsLogging);
tryImplementation(LogFactory::useLog4J2Logging);
tryImplementation(LogFactory::useLog4JLogging);
tryImplementation(LogFactory::useJdkLogging);
tryImplementation(LogFactory::useNoLogging);
}
public static Log getLog(Class<?> clazz) {
return getLog(clazz.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);
}
}
...
}
通过上面两步，我们获取到日志对象是Log接口的某个实现类，以Slf4jLoggerImpl类为例，它的内部持有了一个SLF4J库的Logger对象，最终的日志打印都是交给SLF4J 的logger处理的
