Spring Boot config precedence: command line beats a process variable

Force the collision

The child receives RELAY_BATCHSIZE=29 and --relay.batch-size=31. RelaySettingsProcessTest asserts BOUND_BATCH=31. This is an effective-value check, not an inspection of two sources in isolation. The earlier startup test covered command line against a programmatic default; this one uses an actual inherited environment variable.

The operator must know which source wins. A batch size of 31 instead of 29 changes a worker tick budget, while a timeout override can change the number of requests held in flight. The polling limit gives that setting an operational consequence.

Keep the argument visible to review

A launcher may append flags after an operator sets environment variables. Review the final process command, not just its deployment manifest. Do not put credentials in command-line arguments where process listings may expose them. The test proves only one plain integer collision; it does not model a secret source or multiple profiles.

Checked source

RELAY_BATCHSIZE=29 java -cp "$CLASSPATH" in.aitrove.contracts.RelaySettingsProcessProbe --relay.batch-size=31
# BOUND_BATCH=31

Verification boundary

RelaySettingsProcessTest.commandLineWinsOverTheProcessEnvironment. The source kit contains the full test and entry point.

Common Mistakes

• Do not infer the effective value from the environment alone.
• Do not put a password in a command-line flag for a convenient override.
• Do not assume every property source has the same precedence as this pair.

Read next

Spring Boot environment binding: prove the value in a child JVM, Spring Boot command-line properties: test the effective value at startup, Spring Boot configuration sources: test each deployment path, not a guessed order, Spring outbox polling: cap work per tick and measure backlog age.