Spring Boot external config file: bind the value the process actually loads

Load a real file

BootRelaySettingsTest writes application.properties into a JUnit temporary directory. It starts a non-web SpringApplication context with spring.config.additional-location set to that directory URI. The file supplies relay.batch-size=17 and relay.timeout=750ms; the bound RelaySettings record reports those values instead of the programmatic defaults of 8 and 2s. This is a real file read, not a MapPropertySource inserted after startup.

Boot resolves additional locations early. A directory URI needs its trailing separator so the loader can look for application.properties inside it. The test obtains that URI from Path.toUri rather than joining a platform-specific path string. The source matrix now has a checked file row, but a mounted volume with different permissions still needs a deployment test.

Keep the file operationally boring

Store only non-secret relay settings in the example file. A mounted secret needs access controls, rotation and an error policy that does not print its value. Treat a missing additional location as a startup or rollout decision; do not silently assume the intended file was read just because the application starts with defaults.

The startup validator checks value ranges after binding. It cannot tell whether a plausible value came from the intended source. An effective-settings diagnostic can report selected non-secret values and their origins to operators, while omitting credentials.

Checked source

Files.writeString(configDirectory.resolve("application.properties"),
    "relay.batch-size=17\nrelay.timeout=750ms\n");
try (var context = app().run(
    "--spring.config.additional-location=" + configDirectory.toUri())) {
    assertEquals(17, context.getBean(RelaySettings.class).batchSize());
}

Verification boundary

BootRelaySettingsTest.additionalPropertiesFileOverridesPackagedDefaults. The excerpt is shortened or a labelled design sketch; the kit contains the checked tests.

Costs and limits

The test uses one local temporary file and one process. It does not exercise containers, permissions on a production mount, a remote secret store or profile-specific file selection.

Common Mistakes

• Do not append a filename where Boot expects a directory location.
• Do not infer that a missing config file was loaded from a plausible default value.
• Do not log credentials while reporting effective settings.

Read next

Spring Boot file versus command line: assert the bound result, Spring Boot config validation: separate valid syntax from a safe relay setting, Spring Boot configuration sources: test each deployment path, not a guessed order, Spring Boot configuration properties: bind values and reject bad startup input.

Continue with checked Boot startup

Continue with Spring Boot config import: fail startup when a required file is missing, Spring Boot optional config import: know which default survives.

Checked config-data continuation

Continue with Spring Boot extensionless config file: give the loader a properties hint.