Logback Groovy配置支持的移除
自logback 1.2.9版本起，logback核心库不再原生支持使用groovy脚本进行配置。这一重大变更导致依赖logback.groovy配置文件的项目在升级logback版本后会遇到配置加载失败的问题。
变更溯源：代码层面分析 在Logback 1.2.8版本中，ch.qos.logback.classic.util.ContextInitializer类的configureByResource方法清晰地包含了对.groovy和.xml两种文件扩展名的处理逻辑。它会检查资源URL的后缀，并根据后缀调用相应的配置器（GafferUtil.runGafferConfiguratorOn用于Groovy，JoranConfigurator用于XML）。
// Logback 1.2.8 configureByResource 简化版
public void configureByResource(URL url) throws JoranException {
// ...
final String urlString = url.toString();
if (urlString.endsWith("groovy")) {
// 调用 Groovy 配置器
GafferUtil.runGafferConfiguratorOn(loggerContext, this, url);
} else if (urlString.endsWith("xml")) {
// 调用 Joran XML 配置器
JoranConfigurator configurator = new JoranConfigurator();
configurator.doConfigure(url);
} else {
throw new LogbackException("Unexpected filename extension...");
}
}然而，在Logback 1.2.9版本中，该方法被修改，移除了对.groovy文件后缀的直接处理逻辑。
// Logback 1.2.9 configureByResource 简化版
public void configureByResource(URL url) throws JoranException {
// ...
final String urlString = url.toString();
if (urlString.endsWith("xml")) {
// 仅保留 Joran XML 配置器
JoranConfigurator configurator = new JoranConfigurator();
configurator.doConfigure(url);
} else {
// 任何非 XML 文件都将抛出异常
throw new LogbackException("Unexpected filename extension...");
}
}从上述代码对比中可以看出，Logback 1.2.9明确移除了对Groovy配置器的调用，并将其归类为“意外的文件扩展名”，从而引发错误。
引发此变更的原因：安全漏洞 Logback官方移除Groovy配置支持的主要原因是出于安全考虑，以应对CVE-2021-42550等漏洞。Groovy作为一种强大的动态语言，其配置能力虽然灵活，但也可能被恶意利用，例如通过配置脚本执行任意代码，尤其是在日志配置如此普遍且敏感的场景中。Logback官方在发布新闻中明确指出：“移除了Groovy配置支持。由于日志配置的普及性以及Groovy配置的强大功能，出于安全原因，此功能不太可能被恢复。”
识别问题：常见的错误信息 当项目升级到Logback 1.2.9或更高版本，并且仍然使用logback.groovy作为配置文件时，通常会遇到以下类似的错误信息：
Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
ch.qos.logback.core.LogbackException: Unexpected filename extension of file [file:/[your-project-path]/build/resources/main/logback.groovy]. Should be either .groovy or .xml
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:67)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:140)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
...这个错误明确指示了文件扩展名不被支持，并建议使用.groovy或.xml（尽管Logback 1.2.9+已不再支持原生.groovy）。实际上，这是因为旧的错误消息模板没有及时更新，但核心问题是Groovy支持的移除。
解决方案
面对Logback Groovy配置支持的移除，主要有两种应对策略：
方案一：迁移至XML配置 (推荐)
这是Logback官方推荐且最安全的做法。将现有的logback.groovy配置文件转换为logback.xml格式。XML配置提供了足够的功能来满足绝大多数日志需求，并且是Logback长期稳定支持的配置方式。
示例：将Groovy配置转换为XML
假设你有一个简单的logback.groovy配置：
// logback.groovy 示例
import ch.qos.logback.core.ConsoleAppender
import ch.qos.logback.classic.encoder.PatternLayoutEncoder
def context = loggerContext
def appender = new ConsoleAppender()
appender.context = context
appender.name = "CONSOLE"
def encoder = new PatternLayoutEncoder()
encoder.context = context
encoder.pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
encoder.start()
appender.encoder = encoder
appender.start()
root(INFO, ["CONSOLE"])将其转换为logback.xml：
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
迁移注意事项：
- 语法差异： Groovy配置允许更灵活的编程逻辑，而XML是声明式的。复杂的Groovy逻辑可能需要改写为Logback XML提供的条件语句、变量或自定义Appender/Filter。
- 官方文档： 查阅Logback官方文档中关于XML配置的部分，了解所有可用的元素和属性。
- 测试： 转换后务必彻底测试日志输出，确保所有Appender、Logger和级别设置都按预期工作。
方案二：使用第三方插件恢复Groovy支持 (谨慎选择)
如果确实有强烈的需求继续使用Groovy配置，例如项目中有大量复杂的Groovy配置逻辑难以快速迁移，可以考虑使用第三方社区维护的插件。
插件示例：virtualdogbert/logback-groovy-config GitHub上有一个名为virtualdogbert/logback-groovy-config的项目，旨在为Logback 1.2.9+版本重新引入Groovy配置支持。
- 项目地址: https://github.com/virtualdogbert/logback-groovy-config
使用注意事项：
- 安全性： 使用第三方插件意味着你将重新引入Logback官方出于安全考虑而移除的功能。虽然该插件可能旨在安全地恢复功能，但仍需自行评估其安全性。请务必了解并接受潜在的风险。
- 维护性： 第三方插件的维护情况可能不如官方库。未来Logback版本的更新可能导致插件失效或需要更新。
- 依赖管理： 需要将该插件作为项目依赖添加到构建配置中。
Maven 示例依赖：
com.github.virtualdogbert logback-groovy-config 1.2.11
Gradle 示例依赖：
implementation 'com.github.virtualdogbert:logback-groovy-config:1.2.11' // 请检查最新版本
添加依赖后，Logback应该能够再次识别并加载logback.groovy文件。
总结
Logback 1.2.9+版本移除Groovy配置支持是出于重要的安全考量。对于大多数项目而言，将日志配置迁移到XML格式是最佳实践，它既安全又稳定，并且得到Logback官方的长期支持。如果确实无法避免使用Groovy配置，可以考虑使用第三方插件，但务必充分理解并接受其带来的潜在安全和维护风险。在任何情况下，升级Logback版本后，都应进行全面的日志功能测试，以确保日志系统正常运行。
