Log4j1迁移Log4j2启动报错：Logger properties未提供name属性

嘿，我来帮你搞定这个迁移报错！从你给出的日志、配置信息，再结合你8月4日更新的安装流程细节，问题的根源其实很清晰：

问题到底出在哪？ #

先看启动日志里的关键前置信息：

2022-07-29 12:51:41,271 main DEBUG Reconfiguration started for context[name=55054057] at URI file:/workspaces/ebsprep-logicload/app/cfg/logicload.properties

你的logger.properties其实已经成功加载了（日志里能看到它初始化了AConsole、RollingFile这些Appender，LoggerContext也启动OK了），但之后Log4j2又触发了一次重新配置——这次它误把业务配置文件logicload.properties当成了日志配置文件去加载。

而你的应用安装流程会重命名这类旧文件，logicload.properties里根本没有Log4j2要求的Logger命名属性，自然就抛出了No name attribute provided for Logger properties这个异常。

快速修复方案 #

给你三个按推荐程度排序的解决办法：

1. 强制指定Log4j2的配置文件（最推荐） #

启动应用时，通过JVM参数明确告诉Log4j2该用哪个配置文件，彻底避免它乱扫描：

-Dlog4j.configurationFile=file:/workspaces/ebsprep-logicload/app/cfg/logger.properties

如果不方便改启动参数，也可以在LogicLoad的main方法最开头加上代码强制设置：

System.setProperty("log4j.configurationFile", "file:/workspaces/ebsprep-logicload/app/cfg/logger.properties");

2. 修改业务配置文件的名字 #

既然安装流程会动这些文件，不如直接把logicload.properties改成Log4j2不会识别的名字，比如：

• 改成logicload-app.properties
• 或者把业务配置单独放到一个子目录里，比如cfg/biz/，让Log4j2扫描不到

3. 自定义配置工厂过滤文件（适合复杂场景） #

如果前两种方法都不适用，你可以自定义PropertiesConfigurationFactory，在加载配置时过滤掉业务文件，但这个方法相对繁琐，一般前两种就足够解决问题了。

怎么确认修复成功？ #

重启应用后，看日志里不会再出现Reconfiguration started for context... logicload.properties的行，同时没有ConfigurationException抛出，应用正常启动、日志能正常输出，就说明问题解决啦！

内容的提问来源于stack exchange，提问作者Giovane Kauer