Logback Groovy配置支持的移除
自logback 1.2.9版本发布以来，许多依赖logback.groovy文件进行日志配置的用户遇到了一个意料之外的问题：原先运行良好的groovy配置文件突然失效，并在日志初始化过程中抛出以下警告和异常：
Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
ch.qos.logback.core.LogbackException: Unexpected filename extension of file [file:/[myproj]/build/resources/main/logback.groovy]. Should be either .groovy or .xml
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:67)
...这个错误信息明确指出，Logback不再识别.groovy作为有效的配置文件扩展名。为了理解这一变化，我们可以对比Logback 1.2.8和1.2.9版本中ch.qos.logback.classic.util.ContextInitializer类的configureByResource方法的实现。
在Logback 1.2.8版本中，该方法明确包含了对.groovy文件的处理逻辑：
// 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")) {
// XML配置处理
// ...
} else {
throw new LogbackException("Unexpected filename extension of file [" + url.toString() + "]. Should be either .groovy or .xml");
}
}然而，在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")) {
// 仅保留XML配置处理
// ...
} else {
// 其他文件扩展名直接抛出异常
throw new LogbackException("Unexpected filename extension of file [" + url.toString() + "]. Should be either .groovy or .xml");
}
}通过对比可以清晰地看到，Logback 1.2.9版本移除了对Groovy配置文件的原生支持。
移除的深层原因：安全考量
Logback官方移除Groovy配置支持并非随意之举，其核心原因是出于安全考虑。此变更直接响应了CVE-2021-42550这一高危漏洞，并记录在LOGBACK-1591中。
CVE-2021-42550漏洞指出，Logback的Groovy配置功能，由于其强大的动态执行能力，可能被恶意利用。Groovy配置文件本质上是可执行代码，允许在配置过程中执行任意Java或Groovy代码。如果攻击者能够控制或篡改logback.groovy文件，他们就可以通过日志配置在应用程序中注入并执行恶意代码，从而导致远程代码执行（RCE）等严重安全问题。
Logback官方对此的解释是：“日志记录如此普遍，而使用Groovy进行配置可能过于强大，出于安全原因，此功能不太可能恢复。”这意味着Logback的核心开发者认为，Groovy配置的灵活性和强大功能虽然在某些场景下提供了便利，但其带来的潜在安全风险远超其益处，尤其是在日志这种基础且无处不在的组件中。
应对策略与替代方案
面对Logback官方移除Groovy配置支持的现状，用户有以下几种应对策略：
1. 官方推荐：迁移至XML配置
这是最安全、最稳定且官方支持的解决方案。Logback的XML配置功能强大且完善，能够满足绝大多数日志配置需求，包括Appender、Logger、Filter、Encoder等。
示例：基本的logback.xml配置
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
<logger name="com.example.myapp" level="DEBUG" additivity="false">
<appender-ref ref="STDOUT" />
</logger>
</configuration>迁移过程通常涉及将logback.groovy中的配置逻辑转换为等效的XML结构。对于复杂的Groovy脚本，这可能需要一些时间和精力进行重构。
2. 第三方解决方案：重新引入Groovy支持
对于那些确实需要Groovy配置的灵活性，或者迁移成本过高的项目，社区中存在第三方插件可以重新引入Groovy支持。一个值得关注的插件是virtualdogbert/logback-groovy-config。
该插件通过提供一个自定义的ContextInitializer或类似机制，在Logback的初始化过程中重新启用对Groovy配置文件的解析和执行。
使用注意事项：
- 安全风险评估： 使用第三方插件重新引入Groovy支持，意味着您需要自行承担由此带来的安全风险。务必仔细审查插件的源代码，确保其没有引入新的漏洞，并且您完全理解其工作原理。
- 维护与兼容性： 第三方插件的维护和Logback官方版本迭代的兼容性可能不如官方支持的XML配置。在Logback升级时，可能需要等待插件更新或自行解决兼容性问题。
- 依赖管理： 您需要在项目中明确添加该第三方插件的依赖，并确保Groovy运行时库也在类路径中。
示例：添加第三方插件依赖（以Maven为例）
<dependencies>
<!-- Logback 核心依赖 -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.9</version> <!-- 或更高版本 -->
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.2.9</version> <!-- 或更高版本 -->
</dependency>
<!-- Groovy 运行时依赖 -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy</artifactId>
<version>3.0.8</version> <!-- 根据需要选择版本 -->
</dependency>
<!-- 第三方 logback-groovy-config 插件 -->
<dependency>
<groupId>com.github.virtualdogbert</groupId>
<artifactId>logback-groovy-config</artifactId>
<version>1.0.0</version> <!-- 检查最新版本 -->
</dependency>
</dependencies>具体使用方式请参考该插件的官方文档。
总结
Logback 1.2.9+版本移除对logback.groovy配置文件的官方支持，是出于对潜在安全漏洞（如CVE-2021-42550）的积极响应。Groovy配置的强大动态执行能力，虽然提供了极大的灵活性，但在日志配置这种核心且敏感的环节，被视为一个不可接受的安全风险。
对于大多数应用而言，推荐的做法是迁移到Logback的XML配置，这不仅是官方支持且最安全的路径，也能满足绝大部分复杂的日志需求。如果项目确实有不可替代的Groovy配置需求，可以考虑使用第三方插件来重新引入支持，但在此之前，务必充分评估其带来的安全风险和维护成本。在任何情况下，安全性都应是日志配置决策中的首要考量。
