从Log4J 1迁移至Log4J2后仍出现log4j.xml相关报错求助

1. 确认类路径中是否仍存在Log4j 1的JAR包 #

• 执行Maven命令 mvn dependency:tree | grep log4j:log4j，排查是否有依赖未被正确排除，比如除docx4j外的其他第三方依赖可能隐式引入Log4j 1。
• 直接检查Tomcat部署目录下的WEB-INF/lib文件夹，手动查找log4j-1.x.x.jar这类文件，确认是否有遗漏的旧JAR未被替换或删除。

2. 排查代码中遗留的Log4j 1引用 #

• 全局搜索项目代码中的org.apache.log4j包相关调用，比如Logger.getLogger()、DOMConfigurator.configure()这类Log4j 1专属API，确保所有日志调用都切换到org.apache.logging.log4j下的API。
• 检查是否存在自定义的日志初始化逻辑，比如手动指定加载log4j.xml的代码，这类代码会触发Log4j 1的配置解析器。

3. 检查Tomcat全局配置与类路径 #

• 查看Tomcatconf目录下的logging.properties，确认是否配置了Log4j 1相关参数，或是否存在全局的Log4j 1配置文件。
• 检查Tomcat的lib目录，确认是否有系统级别的Log4j 1 JAR包被部署，这会导致所有Web应用都加载旧版本的Log4j。

4. 追踪Log4j 1配置文件的加载来源 #

• 在Tomcat启动参数中添加-Dlog4j.debug，启动后查看详细日志，Log4j 1会输出它正在尝试加载的配置文件路径，通过这个路径定位残留的log4j.xml或log4j.properties文件。
• 检查项目各模块的resources目录，确认是否有遗漏的log4j.xml/log4j.properties未被删除或替换为log4j2.xml。

5. 排查第三方组件的隐式Log4j 1依赖 #

• 部分老旧第三方组件可能将Log4j 1的类直接打包到自身JAR中，而非通过Maven依赖引入。可以解压可疑的JAR包，检查内部是否包含org.apache.log4j路径下的类文件，针对这类组件需替换为兼容Log4j 2的版本，或添加Log4j 1到2的桥接包（log4j-1.2-api）临时过渡。

内容的提问来源于stack exchange，提问作者Alexis Dufrenoy