本文旨在解决使用 jpackage 打包 java 应用程序为 windows exe 后，log4j2 日志系统无法正常工作，特别是无法将日志文件写入指定应用程序根目录的问题。核心问题在于日志系统初始化时机与自定义系统属性设置的冲突。教程将详细分析问题根源，并提供通过调整主类中 log4j2 日志器初始化顺序的解决方案，确保日志文件能正确生成并写入预期位置。
Log4j2 在 jpackage 打包 EXE 中日志失效的解决方案
在使用 jpackage 工具将 Java 应用程序打包为 Windows 可执行文件（EXE）时，开发者可能会遇到 Log4j2 日志系统无法按预期工作的问题。具体表现为，当直接运行应用程序的 JAR 包时日志功能正常，但运行生成的 EXE 文件时，日志文件却无法创建或创建在错误的目录。本教程将深入探讨这一问题，并提供一个可靠的解决方案。
问题描述与背景
一个常见的场景是，应用程序需要将日志文件写入其自身的安装目录或根目录，而不是当前工作目录。这通常通过在 Log4j2 配置文件中使用一个系统属性（例如 ${app.root}）来指定日志路径。在应用程序启动时，通过 Java 代码动态获取应用程序的根目录，并将其设置为系统属性，然后重新加载 Log4j2 配置。
例如，log4j.properties 文件可能包含如下配置：
# Root logger option
log4j.rootLogger=INFO, DEBUG, file, stdout
# Direct log messages to a log file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=${app.root}/application.log
log4j.appender.file.MaxFileSize=200KB
log4j.appender.file.MaxBackupIndex=4
log4j.appender.file.layout.ConversionPattern=%i %-6p [%-30c{1} :%4L] %m%n
log4j.appender.file.layout=MyPatternLayoutWithQualifiedPath
# Direct log messages to stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout.ConversionPattern=%i %-6p [%-30c{1} :%4L] %m%n
log4j.appender.stdout.layout=MyPatternLayoutWithQualifiedPath在应用程序的主类 Main 中，通常会在 main 方法的早期阶段执行以下逻辑来设置 app.root 属性并重新加载 Log4j2 配置：
public class Main {
// 假设这里可能有一个静态的Logger实例
// private static final Logger log = LoggerFactory.getLogger(Main.class); // 原始位置
public static void main(String[] args) {
// 启用Log4j1兼容模式
System.setProperty("log4j1.compatibility", "true");
// 获取应用程序根目录
URL mySource = Main.class.getProtectionDomain().getCodeSource().getLocation();
File applicationRootDirectory = new File(new File(mySource.getPath()).getParent());
// 设置app.root系统属性
System.setProperty("app.root", applicationRootDirectory.getAbsolutePath().replaceAll("%20", " "));
// 重新加载Log4j2配置
LoggerContext.getContext(false).reconfigure();
// rest of Main class...
}
}这种设置在直接运行 application.jar 时通常工作正常。然而，当使用 jpackage 命令（例如以下示例）打包成 EXE 后：
jpackage.exe ^ --name "the name of the app" ^ --app-version %version% ^ --vendor "vendor name" ^ --icon "icon.ico" ^ --license-file license.txt ^ --file-associations file-association.properties ^ --input input_directory ^ --main-jar application.jar ^ --main-class path.to.MainClass ^ --type exe ^ --win-per-user-install ^ --win-dir-chooser ^ --win-menu ^ --win-menu-group menuGroupName ^ --win-shortcut
运行生成的 application.exe 时，日志文件却无法在 ${app.root} 指定的路径下创建。如果将 log4j.appender.file.File 直接设置为 application.log（不使用 ${app.root}），日志文件虽然可以创建，但会出现在应用程序的当前工作目录，而非预期的应用程序根目录。
问题根源分析
问题的核心在于 Log4j2 日志器的初始化时机。在 Java 应用程序中，静态字段会在类加载时被初始化。如果在一个类中声明了一个静态的 Logger 实例（例如 private static final Logger log = LoggerFactory.getLogger(Main.class);），那么这个日志器会在 main 方法执行之前，即 Main 类被加载时就被初始化。
当 Log4j2 日志器初始化时，它会尝试加载日志配置。如果此时 app.root 系统属性尚未设置，或者 Log4j2 配置尚未被重新加载，那么日志系统将使用默认的或旧的配置，无法正确解析 ${app.root} 变量。
虽然在 main 方法中调用了 LoggerContext.getContext(false).reconfigure() 来重新加载配置，但如果静态日志器已经在之前初始化，那么它所持有的配置可能仍然是旧的。在 JAR 包环境下，这种时序问题可能不那么明显，或者由于 JVM 启动机制的微小差异，重新配置可能在第一次日志调用前生效。但在 jpackage 打包的 EXE 环境中，这种时序变得更加严格和关键，导致重新配置未能及时影响到已初始化的日志器。
解决方案
解决此问题的关键是确保在任何日志器被初始化 之前，app.root 系统属性已经设置完毕，并且 Log4j2 的配置已经被重新加载。这意味着，日志器的获取操作必须在 main 方法中动态执行，而不是作为静态字段初始化。
将 Logger 实例的获取从静态字段定义移动到 main 方法中，并在设置系统属性和重新配置日志上下文之后再获取，可以确保日志器在正确的配置下初始化。
以下是修改后的 Main 类代码示例：
import org.apache.logging.log4j.core.LoggerContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.io.File;
import java.net.URL;
public class Main {
// 不再在类字段中静态初始化Logger
// private static final Logger log = LoggerFactory.getLogger(Main.class); // 移除此行
public static void main(String[] args) {
// 1. 启用Log4j1兼容模式（如果使用Log4j1风格的properties文件）
System.setProperty("log4j1.compatibility", "true");
// 2. 获取应用程序的根目录
URL mySource = Main.class.getProtectionDomain().getCodeSource().getLocation();
File applicationRootDirectory = new File(new File(mySource.getPath()).getParent());
// 3. 设置app.root系统属性
System.setProperty("app.root", applicationRootDirectory.getAbsolutePath().replaceAll("%20", " "));
// 4. 重新加载Log4j2配置，确保它能识别新的app.root属性
LoggerContext.getContext(false).reconfigure();
// 5. 在配置重新加载后，再获取Logger实例
Logger log = LoggerFactory.getLogger(Main.class);
// 至此，log实例将使用已更新的配置，能够正确解析${app.root}
log.info("应用程序启动，日志文件应已创建在: {}", System.getProperty("app.root"));
// 应用程序的其余逻辑
// ...
}
}通过将 Logger log = LoggerFactory.getLogger(Main.class); 这行代码移动到 System.setProperty("app.root", ...) 和 LoggerContext.getContext(false).reconfigure(); 之后，我们确保了当 Log4j2 第一次创建 Logger 实例时，它已经拥有了正确的配置上下文，从而能够正确解析 log4j.properties 中定义的 ${app.root} 变量。
注意事项与最佳实践
- 初始化时机： 始终牢记 Java 中静态字段的初始化时机早于 main 方法的执行。如果日志配置依赖于运行时动态设置的系统属性，务必在获取任何日志器实例之前完成这些设置和配置的重新加载。
- 兼容性： 如果您使用的是 Log4j1 风格的 .properties 文件，确保设置 log4j1.compatibility 系统属性为 true，以便 Log4j2 能够正确解析。
- 日志路径： 建议在应用程序启动初期，打印出解析后的日志文件路径，以便在调试时确认路径是否正确。
- 错误处理： 考虑在获取应用程序根目录或设置系统属性时加入错误处理机制，以应对文件路径解析失败等异常情况。
- jpackage 环境： jpackage 创建的 EXE 环境与直接运行 JAR 包可能存在细微差异，尤其是在类加载和资源路径解析方面。因此，针对 jpackage 环境进行充分测试至关重要。
总结
当使用 jpackage 将 Java 应用程序打包为 EXE 后，Log4j2 日志功能异常，特别是涉及到动态设置日志文件路径时，其根本原因通常是日志器初始化时机与自定义配置加载的时序问题。通过将日志器实例的获取推迟到系统属性设置和日志上下文重新配置之后，可以有效地解决这一问题，确保日志系统在正确的配置下工作，并将日志文件写入预期的位置。这一解决方案强调了在开发打包应用程序时，对初始化顺序和环境差异的细致考量。
