Log4j1.x迁2.x用桥接器时调用DOMConfigurator.configureAndWatch的问题

你目前没观测到日志异常，本质是因为Log4j 1.x桥接包（log4j-1.2-api）里的DOMConfigurator类是为了兼容字节码调用做的存根实现，所有方法默认是空逻辑，不会抛出类找不到或者方法不存在的错误，但实际存在不少隐性风险：

• 配置加载逻辑完全静默失效
  桥接包中的DOMConfigurator不会解析你原有的Log4j 1.x格式XML配置，也不会把配置规则同步给Log4j 2核心。你现在看到日志正常输出，基本是两种情况：要么Log4j 2启动时自动加载了classpath下的log4j2.xml配置；要么Log4j 2默认配置的输出规则刚好和你当前的测试预期匹配，实际上你原来配置的自定义日志级别、Appender路由、滚动策略、过滤规则大概率根本没有生效。
• 热更新能力完全丢失
  原生Log4j 1.x的configureAndWatch()会启动后台线程定期扫描配置文件变更、自动重载配置，但桥接包中的该方法既不会加载指定路径的配置文件，也不会启动有效的配置监听线程。后续线上如果需要动态调整日志级别、修改输出路径、调整滚动规则，就算你改了原来的log4j.xml配置文件，日志行为也不会有任何变化，很容易出现日志漏打、敏感日志外泄、磁盘被日志打满这类问题，而且全程不会抛出任何错误，排查成本极高。
• 特定版本存在内存泄漏风险
  部分早期版本的桥接包中，configureAndWatch()会错误创建一个无实际逻辑的守护监听线程，这个线程没有绑定Log4j 2的生命周期关闭钩子，如果你的应用是跑在Tomcat这类需要热部署的容器里，应用重加载时这个线程不会被回收，多次热部署后会触发Metaspace内存溢出。
• 自定义配置参数被直接忽略
  如果你在调用configureAndWatch()时传入了非默认的配置文件路径、自定义的配置解析器、间隔时间参数，这些参数会被存根方法直接丢弃，你指定位置的配置文件永远不会被加载。

桥接器的兼容边界仅覆盖日志打印相关的API调用，所有Log4j 1.x的配置加载、自定义日志组件扩展相关的类都仅做类级别的兼容，不提供实际功能，这也是官方文档明确要求不能调用DOMConfigurator、PropertyConfigurator类的核心原因。

如果需要保留配置热更新能力，不需要自己写代码调用配置方法，直接在Log4j 2的配置文件根节点加上monitorInterval="30"这类参数即可，Log4j 2会自动按指定间隔扫描配置变更并重载。

内容的提问来源于stack exchange，提问作者Volodymyr Bezuglyy