Spring Boot 3.2部署Tomcat后日志文件mylog.log未生成求助

1. 确认配置加载时机与优先级 #

Spring Boot的日志系统初始化极早，远早于@PropertySource注解的加载时机——@PropertySource是在Spring上下文初始化阶段才生效的，这时候日志系统已经完成初始化，外部配置里的日志属性自然不会被读取。

解决思路：放弃@PropertySource，改用Spring Boot原生的外部配置加载方式：

• 在Tomcat的bin/catalina.sh中添加JVM参数，指定外部配置文件路径：

  JAVA_OPTS="$JAVA_OPTS --spring.config.location=/opt/tomcat/latest/conf/application.properties"
  

  这种方式会在应用启动最早期加载配置，能覆盖默认的日志属性。

2. 校验日志属性的正确性 #

不同Spring Boot版本的日志属性名可能有差异，确保你用的属性与当前版本匹配：

• Spring Boot 2.x及以后：
  • logging.file.name：指定日志文件的完整路径（如/opt/tomcat/latest/logs/mylog.log）
  • logging.file.path：指定日志目录，此时日志文件默认名为spring.log

  注意：如果同时设置logging.file.name和logging.file.path，logging.file.name优先级更高，logging.file.path会被忽略。

• 若使用旧版本（1.x），属性名为logging.file（完整路径）和logging.path（目录）。

3. 验证外部配置是否被正确读取 #

在应用中添加代码，确认配置是否加载成功：

import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;

@Component
public class ConfigChecker {
    private final Environment env;

    public ConfigChecker(Environment env) {
        this.env = env;
    }

    @PostConstruct
    public void checkLogConfig() {
        System.out.println("logging.file.name: " + env.getProperty("logging.file.name"));
        System.out.println("logging.file.path: " + env.getProperty("logging.file.path"));
    }
}

重启应用后查看Tomcat的catalina.out，如果输出为null，说明外部配置根本没被读取——检查配置文件路径是否正确、文件格式是否有语法错误（比如键值对格式错误）。

4. 排查Tomcat的干扰 #

• 检查Tomcat的conf/logging.properties：确认其中没有设置与Spring Boot日志冲突的配置，比如强制指定了日志文件路径或日志实现。
• 查看Tomcat的环境变量：检查JAVA_OPTS中是否有-Dlogging.file.name、-Dlogging.file.path这类系统属性，它们会覆盖应用配置中的对应属性。

1. 查看Tomcat核心日志 #

Ubuntu上Tomcat的catalina.out是最直接的日志来源，路径通常为/opt/tomcat/latest/logs/catalina.out。用以下命令实时查看：

tail -f /opt/tomcat/latest/logs/catalina.out

日志系统初始化失败的信息（如权限问题、路径不存在、属性解析错误）都会在这里输出。

2. 启用Spring Boot调试日志 #

在Tomcat的bin/catalina.sh中添加调试参数，让Spring Boot输出更详细的启动过程：

JAVA_OPTS="$JAVA_OPTS -Ddebug"

重启后，catalina.out会包含日志系统初始化的完整流程，比如加载了哪些配置文件、是否识别到日志属性、创建日志文件时的异常堆栈。

3. 检查系统级日志 #

如果Tomcat是通过systemd管理的，用以下命令查看系统层面的错误：

journalctl -u tomcat.service -f

可以排查是否有AppArmor（Ubuntu默认安全模块）阻止应用写入指定目录，或者系统层面的权限/资源限制。

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