WebSphere Liberty上IBM JSR 352批处理任务日志为空问题求助

我之前维护Liberty上的JSR352批处理应用时也碰到过类似情况，结合经验给你梳理几个可能的原因，你可以逐一排查：

1. 日志级别配置限制 #

虽然日志文件能生成，但如果Liberty的日志级别设置过高，会过滤掉所有符合输出条件的日志内容：

• 检查你的server.xml中的日志配置，确保批处理相关包的日志级别足够低：

  <logging traceSpecification="com.ibm.ws.batch.*=info, javax.batch.*=info" />
  

  可以临时把级别改成finest测试，如果此时part.log有内容，说明之前的级别设置过滤了日志输出。
• 同时确认全局日志配置没有覆盖joblogs的单独设置（比如logRetentionPolicy这类配置一般不会导致空文件，但也可以快速核对）。

2. 日志框架桥接问题 #

如果你的批处理代码用了第三方日志框架（比如Log4j2、SLF4J），但没正确配置与Liberty默认JUL（Java Util Logging）的桥接，日志会无法输出到joblogs中：

• 比如用Log4j2时，需要引入log4j-jul桥接包，并在Liberty的server.xml中配置类加载器包含该包；
• 或者直接改用JSR352规范推荐的BatchLogger输出日志，确保日志能被Liberty的批处理日志系统捕获。

3. 任务异常未被正确记录 #

有时候批处理任务在启动或初始化阶段就失败了，但异常不会写入part.log，而是输出到Liberty的系统日志：

• 检查Liberty的messages.log和trace.log，看看有没有com.ibm.ws.batch相关的错误信息，比如任务启动失败、步骤初始化异常、数据源连接错误等；
• 这些启动阶段的异常通常不会出现在part.log里，但会导致任务没有实际执行，从而part.log为空。

4. 文件系统权限或路径问题 #

虽然文件能生成0字节，但也要确认Liberty进程是否有完整的写入权限：

• 在Windows环境下，检查C:\web servers\liberty_profile\...\joblogs文件夹的权限，确保运行Liberty的用户有写入、修改权限；
• 可以手动尝试往生成的part.1.log里写入内容，如果无法写入，说明权限存在问题。

5. 旧版本Liberty的已知bug #

你使用的wlp-javaee7-17.0.0.1是2018年的旧版本，可能存在批处理日志相关的bug：

• 比如某些场景下，当任务没有产生任何日志输出（甚至没有基础的启动日志）时，框架会生成空的part.log；
• 可以尝试升级到该版本的最新fix pack，或者切换到较新的Liberty版本（比如Java EE8或Jakarta EE版本），看看问题是否解决。

6. 批处理任务逻辑未执行 #

如果任务的XML配置或代码逻辑有问题，导致任务没有实际执行任何步骤，自然不会有日志输出：

• 检查job XML的步骤定义，确认步骤的start条件、next跳转逻辑是否正确，有没有被跳过执行；
• 可以在任务的入口（比如ItemReader.open()方法）添加一条明确的日志输出，然后运行任务，看是否能写入part.log，以此验证任务是否真正执行。

内容的提问来源于stack exchange，提问作者Java guy