杂谈 : 日志门户 slf4j 如何集成日志框架的

976 阅读5分钟

首先分享之前的所有文章 , 欢迎点赞收藏转发三连下次一定 >>>> 😜😜😜
文章合集 : 🎁 juejin.cn/post/694164…
Github : 👉 github.com/black-ant
CASE 备份 : 👉 gitee.com/antblack/ca…

一 . 前言

这一篇讨论一点简单得东西 , 主要来了解一下什么叫日志门户 , 他又是怎么集成的 .

二 . 日志门户

阿里出版的 Java开发手册里面有这样一个强制规约 :

应用中不可直接使用日志系统(Log4j、Logback)中的API,而应依赖使用日志框架 (SLF4J、JCL--Jakarta Commons Logging)中的API,使用门面模式的日志框架,有利于维护和各个类的日志处理方式统一。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);

那么为什么要这么用 ?

什么叫日志门户 ?

Simple Logging Facade for Java(SLF4J)作为各种日志框架(例如Java.util.Logging、logback、log4j)的简单门面或抽象,允许最终用户在部署时插入所需的日志框架。

简单点说 , 门户的目的是为了解耦 , SLF4J 就像一个抽象类一样 , 不关注具体的实现 . 在使用的时候 , 也可以灵活的使用 .

三 . 集成方式

类关系图

image.png 可以看到 , 核心前置处理就是初始化阶段 , 用来将对应的插件加载进入 , 分析起来还是以 Spring 为例 :

3.1 初始化阶段

// S1 : 初始化的发起
// Log 的加载同样是在 LogFactory 环节进行的 
C- SpringApplication
private static final Log logger = LogFactory.getLog(SpringApplication.class);


// S2 : LogFactory 发起处理流程 , 加载 Adapter 适配器
getLog -> LogAdapter.createLog(name);


// S3 : LogAdapter 中加载具体的处理类
public static Log createLog(String name) {
    switch(logApi) {
    // 代码很简单 , 也很关键 , 按照类型去创建
    // 这里也可以看到 , 使用日志框架就会有耦合 , 所以使用门户更合理
    case LOG4J:
        return LogAdapter.Log4jAdapter.createLog(name);
    case SLF4J_LAL:
        return LogAdapter.Slf4jAdapter.createLocationAwareLog(name);
    case SLF4J:
        return LogAdapter.Slf4jAdapter.createLog(name);
    default:
        return LogAdapter.JavaUtilAdapter.createLog(name);
    }
}


// S4 : 调用具体的实现类(以 Slf4j 为例)
C- org.slf4j.LoggerFactory # getILoggerFactory 
    1- performInitialization () : 获取 LoggerFactoru -> S5 
        - bind() : 扫描类
        - StaticLoggerBinder.getSingleton().getLoggerFactory() : 返回最终对象
    2- iLoggerFactory.getLogger(name) : 通过 Factory 获取 Logger 对象 

// S5 : Binder绑定具体的实现类
C- org.slf4j.LoggerFactory # bind()
    ?- 整个过程中主要分为以下几个步骤
    1- 获取实现类 
        |- Set<URL> staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
    2- 多绑定校验 : 这也是如果有多个版本不同或者类型不同的log框架时会提醒的原因
        |- reportMultipleBindingAmbiguity
    3- 打印实际绑定类型 (可以看到最终的实现类)
        |- reportActualBinding(staticLoggerBinderPathSet);

 
// S5-1 : 具体执行类的加载
// STATIC_LOGGER_BINDER_PATH -> org/slf4j/impl/StaticLoggerBinder.class
Set<URL> staticLoggerBinderPathSet = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
    ?- 这里是通过扫描包的方式去加载不同实现框架对其的实现
        

补充 : 兼容方式 既然时为了解耦 , 就不能在其中引入实际的处理类 , 那么它是怎么去集成的呢 ?
在logback 中可以看到这样一个额外的引入 :

jar:file:/D:/java/resource/repo/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class

image.png

这里就可以看出来 , 实际上这种集成方式需要第三方去兼容.例如 log4j 的

jar:file:/D:/java/resource/repo/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class

3.2 实际调用阶段

实际调用中, 我们通过 LoggerFactory.getLogger(Test.class); 发起时 , 会按照上述流程获取最终的实现 Factory 类 , 再通过其 iLoggerFactory.getLogger(name) 获取具体的 Logger 对象 ,此时的对象就已经是实现类了

总结

  • 真正解耦的方式是通过 LogFactory 实现的
  • 当使用 Logger 时 实际上使用的已经是实现类了

四 . Mybatis 类比

当然直接调用很容易理解 , 那么如果是一个框架 , 该如何使用这种特性呢 ?

以 Mybatis 为例 , 看一下如何使用 slf4j + logback 实现 SQL 的输出

之前写过一篇文档 ,从 Log 看 Mybatis 流程 , 我们只需要很简单的两步就实现了 log 输出日志 :

// S1 : 配置Mybatis log 方式
mybatis-plus:
    configuration:
        log-impl: org.apache.ibatis.logging.slf4j.Slf4jImpl
        
// S2 : 配置 Logback    
<logger name="com.apache.ibatis" level="debug"/>
<logger name="java.sql.Connection" level="debug"/>
<logger name="java.sql.Statement" level="debug"/>
<logger name="java.sql.PreparedStatement" level="debug"/>
<logger name="com.gang.test.dao.mapper" level="debug"/>

这里选择的 log impl 为 Slf4jImpl , 由他来实现具体的 log 实现类转发 , 这里面又是哪里实现的?

我们知道 Mybatis Log 的核心处理类为 BaseJdbcLogger , 其中提供了多种不同的 Log 实现类 : StdOutImpl / Slf4jImpl 等

如果我们选择 StdOutImpl , 只能实现简单打印到控制台 , 所以我们通常会使用 Slf4jImpl 或者 Log4jImpl , 以实现打印到日志中并且进行日志抓取.

// 核心 : BaseJdbcLogger 对 Logger 进行处理 , 但是这里能看到 , 实际上 Log 是外部传进来的
public BaseJdbcLogger(Log log, int queryStack) 


// 那么传入的地方是哪里 ? 
在构建 MappedStatement 的时候 , Mybatis 会通过 LogFactory 对 Log 进行构建


// S1 : 加载 Log 实现类
private static void setImplementation(Class<? extends Log> implClass) {
    // 通过构造器反射获取实际的 Log 处理类
    Constructor<? extends Log> candidate = implClass.getConstructor(String.class);
    Log log = candidate.newInstance(LogFactory.class.getName());
    logConstructor = candidate;
}


// S2 : LogFactory # getLog
public static Log getLog(String logger) {
    return logConstructor.newInstance(logger);
}

Mybatis 的适配方式

不同于业务系统具有明确的目的性 , 可以一开始选择使用 slf4j , 如 Mybatis 这类框架无法一开始就明确使用的框架 , 所以 Mybatis 内部的方式为 :都尝试处理 , 如果有处理成功的 , 就不处理后面的了

C- LogFactory : 依次尝试加载不同的日志框架
static {
  tryImplementation(LogFactory::useSlf4jLogging);
  tryImplementation(LogFactory::useCommonsLogging);
  tryImplementation(LogFactory::useLog4J2Logging);
  tryImplementation(LogFactory::useLog4JLogging);
  tryImplementation(LogFactory::useJdkLogging);
  tryImplementation(LogFactory::useNoLogging);
}

注意 , 这里和之前配置的 log-impl 并没有直接联系 , log-impl 在以下环节进行处理


// S1 : 属性加载
C- org.apache.ibatis.session.Configuration
public void setLogImpl(Class<? extends Log> logImpl) {
  if (logImpl != null) {
    this.logImpl = logImpl;
    LogFactory.useCustomLogging(this.logImpl);
  }
}

// S2 : 覆盖为自定义处理类
public static synchronized void useCustomLogging(Class<? extends Log> clazz) {
  setImplementation(clazz);
}

这里也可以看出来 , Mybatis 的处理其实分成了2个步骤 :

  • 按照顺序依次 全量 加载 log 处理实现类
  • 如果自定义 log 实现类 ,通过 覆写 logConstructor 实现自定义处理

总结

不同于主观反射拿到实现类 , 或者多个框架共同实现一个更抽象的接口 , Slf4j 需要日志框架进行主动的适配 , 去实现它的 StaticLoggerBinder 类 , 然后再通过扫包的方式去使用具体的框架类

而通过分析 Mybatis 也看到了不同日志框架带来的影响 , 需要在代码中进行类的耦合 , 以适配不同的日志框架.

如果只是内部业务系统 , 选择 Slf4j 可以带来很多的优势, 如果是写开源框架 , 采用 Mybatis 这种先全量 , 再定制的方式进行使用也是不错的选择