Spring MVC（非Spring Boot）运行时加载环境专属属性文件方案咨询

Alright, let's tackle your setup step by step—since you're working with a non-Spring Boot Spring MVC project, we'll focus on runtime environment resolution, Jenkins pipeline integration, and proven best practices tailored to your stack.

1. Fix Your Property Placeholder Path First #

First, I noticed your current context:property-placeholder config misses the Properties subfolder where your files live. Update it to point to the correct location:

<context:property-placeholder 
    location="classpath:Properties/application-default.properties, classpath:Properties/application-${env}.properties" 
    ignore-unresolvable="true" />

This ensures Spring can locate your property files under src/main/Resources/Properties/.

2. Resolve ${env} at Runtime #

Since this isn't Spring Boot, we'll use JVM system properties to pass the environment identifier when starting your application server:

For Local IDE Testing: #

In your run configuration, add this to the VM options:

-Denv=dev

For Tomcat Deployment (Linux): #

Edit catalina.sh and append the property to JAVA_OPTS:

export JAVA_OPTS="$JAVA_OPTS -Denv=prod"

For Tomcat Deployment (Windows): #

Edit catalina.bat and add:

set JAVA_OPTS=%JAVA_OPTS% -Denv=uat

When your app starts, Spring will resolve ${env} using the system property and load the matching environment file alongside the default one.

3. Jenkins Pipeline Integration #

The golden rule here is to build a single environment-agnostic WAR file, then deploy it to different environments by passing the appropriate env parameter during deployment. Here's a sample Jenkinsfile snippet:

pipeline {
    agent any
    stages {
        stage('Build WAR') {
            steps {
                // Build one WAR (no environment-specific config baked in)
                sh 'mvn clean package -DskipTests'
            }
        }
        stage('Deploy to DEV') {
            steps {
                // Copy WAR to DEV server and restart Tomcat with dev env
                sh 'scp target/your-app.war dev-tomcat:/opt/tomcat/webapps/'
                sh 'ssh dev-tomcat "export CATALINA_OPTS=-Denv=dev && /opt/tomcat/bin/restart.sh"'
            }
        }
        stage('Deploy to PROD') {
            steps {
                // Same WAR, different env parameter for production
                sh 'scp target/your-app.war prod-tomcat:/opt/tomcat/webapps/'
                sh 'ssh prod-tomcat "export CATALINA_OPTS=-Denv=prod && /opt/tomcat/bin/restart.sh"'
            }
        }
    }
}

This avoids maintaining multiple build artifacts and keeps your pipeline clean and maintainable.

4. Critical Best Practices #

• Use Default Config as Single Source of Truth: Store all shared, environment-agnostic settings in application-default.properties. Only put environment-specific overrides (like DB URLs, API keys, log levels) in the environment-specific files to reduce duplication.
• Never Hardcode Environment Values: Avoid writing code like if (env == "prod")—always use @Value to inject properties instead. This keeps your codebase completely environment-agnostic.
• Protect Sensitive Production Configs: Don't commit application-prod.properties (with secrets like DB passwords) to your repo. Instead, place it directly on the production server (e.g., in Tomcat's lib directory) and update the placeholder location to load it from there:

  <context:property-placeholder 
      location="classpath:Properties/application-default.properties, 
               classpath:Properties/application-${env}.properties,
               file:/opt/tomcat/lib/application-${env}.properties" 
      ignore-unresolvable="true" />
  

  The file system path takes precedence, so you can keep secrets out of version control.
• Validate Config Loading: Add a simple endpoint to verify which environment is active and which properties are loaded:

  @Controller
  public class EnvValidationController {
      @Value("${env:unknown}")
      private String activeEnv;
      
      @Value("${app.version:unset}")
      private String appVersion;
      
      @RequestMapping("/env-status")
      @ResponseBody
      public String getEnvStatus() {
          return String.format("Active Environment: %s | App Version: %s", activeEnv, appVersion);
      }
  }
  

• Fail Fast for Critical Environments: If you want to ensure an environment is always specified (no fallback to default only), remove ignore-unresolvable="true"—this will cause the app to fail on startup if the environment file isn't found, preventing accidental misconfigurations.

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