游乐游手机版
首页/编程语言/文章详情

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

时间:2026-04-29 22:59
SpringBoot2 7 x将logback升级到1 3 x以上版本的全过程解析 不少开发者在尝试将SpringBoot 2 7 x项目中的Logback升级到1 3 x或更高版本时,都会遇到一个典型的启动报错。这背后的原因其实很明确:SpringBoot 2 7 x默认依赖的是logback-c

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

不少开发者在尝试将SpringBoot 2.7.x项目中的Logback升级到1.3.x或更高版本时,都会遇到一个典型的启动报错。这背后的原因其实很明确:SpringBoot 2.7.x默认依赖的是logback-classic-1.2.x及以下版本,而到了1.3.x版本,Logback团队移除了一个关键类org.slf4j.impl.StaticLoggerBinder,这个类恰恰是SpringBoot启动时所依赖的。版本不匹配,冲突自然就来了。

一、报错原因分析

要彻底搞清楚这个问题,最好的办法就是顺着源代码走一遍。我们以以下版本组合为例:

spring-boot-2.7.18

logback-classic-1.2.11

SpringBoot应用启动时,会触发LoggingApplicationListener.onApplicationEnvironmentPreparedEvent方法。这个方法的核心任务之一,就是获取一个LoggingSystem的实例。这个过程如下图所示:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

那么,LoggingSystem实例是如何生成的呢?关键在LoggingSystem.get这个方法里:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

这里有个系统属性SYSTEM_PROPERTY,其值为org.springframework.boot.logging.LoggingSystem。它的作用是指定日志系统:

  • 如果这个属性的值是一个LoggingSystem实现类的全限定名(比如org.springframework.boot.logging.logback.LogbackLoggingSystem),SpringBoot就会直接实例化它。
  • 如果值被设为NONE,则会生成一个什么都不做的NoOpLoggingSystem
  • 如果既没指定也不是NONE,SpringBoot就会自动扫描类路径,寻找可用的日志框架并初始化。

拿到LoggingSystem实例后,紧接着就会调用其initialize方法:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

这个方法内部会进一步调用initializeSystem

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

注意这里的CONFIG_PROPERTY,它对应环境变量logging.config,也就是用来指定Logback配置文件路径的。之后,SpringBoot会使用LogbackLoggingSystem.initialize来初始化Logback:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

问题就出在getLoggerContext()这个方法里。我们来看它的源代码:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

看明白了吗?正是在这里,代码直接引用了StaticLoggerBinder.getSingleton().getLoggerFactory()。而在Logback 1.3.x中,这个StaticLoggerBinder类已经被移除了。所以,当SpringBoot 2.7.x试图用老办法初始化新版本的Logback时,类找不到,报错也就成了必然。

二、解决方案

分析完源码,解决方案就清晰了。核心思路就一句话:绕过SpringBoot的自动初始化,让应用自己来管理Logback的启动。

具体操作分三步:

第一步,关闭SpringBoot的日志系统自动配置。 将系统属性 org.springframework.boot.logging.LoggingSystem 的值设置为 none。这样,SpringBoot在启动时就不会尝试去初始化和绑定Logback了。

第二步,同步升级SLF4J。 将Logback升级到1.3.x时,别忘了它的搭档SLF4J也需要同步升级到1.8.x或更高版本。具体的版本对应关系,可以参考相关文档(如《Ja va:logback-classic与slf4j版本对应关系》)。

第三步,更换配置文件路径的指定方式。 如果你之前是通过环境变量 logging.config 来指定Logback配置文件(如logback.xml)的位置,现在需要改为使用Logback原生支持的 logback.configurationFile 环境变量。原因在下面的源码中一目了然:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

(注:上述源码截图来自logback-classic-1.3.15)

其实,这个解决方案在Logback的官网上也有明确说明。下图来自其下载页面:

SpringBoot2.7.x将logback升级到1.3.x以上版本的全过程解析

地址:https://logback.qos.ch/download.html

官网的建议也验证了我们的分析:在Spring Boot等框架中,需要通过设置org.springframework.boot.logging.LoggingSystem=none来禁用其日志系统,并直接使用Logback自身的初始化机制。

三、进一步说明

可能有人会问,为什么一定要换成logback.configurationFile,而不能继续用Spring Boot的logging.config呢?这涉及到Web应用中的初始化顺序问题。

对于部署在Servlet 3.0及以上容器(比如Tomcat)的应用,Logback的初始化通常是由ch.qos.logback.servlet.LogbackServletContainerInitializer这个类来完成的。而Spring Boot自身的初始化则是由org.springframework.web.SpringServletContainerInitializer负责。这两个类都实现了ja vax.servlet.ServletContainerInitializer接口。

关键在于,Servlet容器往往会先执行LogbackServletContainerInitializer。这意味着,在Spring Boot还没来得及插手之前,Logback就已经按照自己的规则初始化完毕了。所以,等到Spring Boot想通过logging.config去配置Logback时,时机已经错过了,配置自然不会生效。

因此,在混合升级的场景下,使用Logback原生支持的logback.configurationFile环境变量来指定配置路径,是确保配置能够被正确加载的唯一可靠方式。

来源:https://www.jb51.net/program/36248647s.htm
上一篇Xrender支持哪些图形格式 下一篇PHP 8.0 的主要特性(第三篇章)
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
PyTorch中使用多维索引张量对高维张量批量索引的正确方法
编程语言 · 2026-07-03

PyTorch中使用多维索引张量对高维张量批量索引的正确方法

本文深入讲解如何在 PyTorch 中利用形状为 [b, k] 的索引张量 B,对形状为 [b, m, n] 的高维张量 A 执行高效批量索引,最终得到 [b, k, n] 的输出。核心思路在于合理扩展索引维度并配合 torch gather 实现精准的逐行抽取。 很多人处理高维张量的批量索引时都会

Go中...操作符解包切片传递可变参数函数
编程语言 · 2026-07-03

Go中...操作符解包切片传递可变参数函数

在 Go 语言中,` ` 运算符放在切片变量后面(如 `slice `)的作用是将该切片“展开”为多个独立参数,专门用于调用那些接受可变参数(` T`)的函数,例如 `append` 或 `fmt Println`。这是一种类型安全的语法糖,并非省略号或通配符,能够帮助开发者更简洁地处理

macOS与WSL2下PHP多版本切换失效问题排查与修复指南
编程语言 · 2026-07-03

macOS与WSL2下PHP多版本切换失效问题排查与修复指南

本文深入分析在 macOS 或 WSL2(Ubuntu)开发环境中,通过 Homebrew 管理 PHP 多版本时,php -v 始终显示旧版本(如 php@5 6)的深层原因,并给出系统性解决方案,覆盖 PATH 冲突、符号链接逻辑、Shell 初始化配置、系统残留配置等关键环节。 遇到这种情况的

PHP JSON解析深层嵌套对象属性访问失败的解决方法
编程语言 · 2026-07-03

PHP JSON解析深层嵌套对象属性访问失败的解决方法

使用 json_decode() 解析 API 返回的 JSON 数据时,经常遇到某个子属性无法正常获取,始终返回 NULL —— 这是许多 PHP 开发者都曾碰到过的棘手问题。通常并非数据丢失,而是对象嵌套层级比预期更深,导致访问路径不正确。 举例来说,你看到返回的 JSON 里有一个 appea

nnU-Net v2预处理卡死问题的成因分析与实用解决指南
编程语言 · 2026-07-03

nnU-Net v2预处理卡死问题的成因分析与实用解决指南

> 使用 nnUNetv2_plan_and_preprocess 处理大规模数据集(例如 704 例样本)时,程序常因多进程加载导致死锁而停滞。核心原因在于默认并发数过高引发资源竞争或 I O 阻塞,适当降低并发数即可稳定完成全量预处理。 你在使用 `nnunetv2_plan_and_prepr