Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Spring Boot does not inject application.yml into beans, and component scanning does not find it. During startup, the ConfigDataEnvironmentPostProcessor loads the file as ConfigData and applies its values to Spring’s Environment. Your beans then read those values from the Environment through @Value, @ConfigurationProperties, or the Binder. The value a component finally receives depends on precedence among property sources, profile-specific files, imports, and the configured locations.
What happens during startup
- The Environment is prepared. Before the application context is refreshed and beans are created, Spring Boot builds the application
Environment, a collection of named property sources. - ConfigData is loaded. The
ConfigDataEnvironmentPostProcessoris anEnvironmentPostProcessor. Its Spring Boot 3.5 API description says it “loads and appliesConfigDatato Spring’sEnvironment,” and the API lists it as present since Spring Boot 2.4.0. It resolves the locations, reads supported files such asapplication.yml, and adds the resulting values as property sources. - Values are available to the Environment. The file’s contents are now queryable by key, such as
server.port, but the YAML document itself is not handed to any component. - Beans bind the values. During context refresh,
@Valueplaceholders and@ConfigurationPropertiesclasses resolve against the Environment. This is why a bean can see values fromapplication.ymlwithout any import of the file.
So the answer to “does application.yml load before my beans?” is yes. The file is read in the environment-preparation phase, which runs before beans are created.
Where Spring Boot looks for the file
The default search locations are described in the Externalized Configuration reference. Do not treat a single filesystem path as universal, because the location depends on where the application is launched and how it is packaged. The default locations, listed from lowest to highest precedence, are:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →| Location | Where it resolves | Relative precedence |
|---|---|---|
classpath:/ |
Root of the classpath, including the root of a packaged JAR | Lowest |
classpath:/config/ |
config package on the classpath |
Higher than classpath:/ |
file:./ |
The current working directory | Higher than the classpath locations |
file:./config/ |
config directory under the working directory |
Higher than file:./ |
file:./config/*/ |
Immediate subdirectories of config |
Highest |
Both application.yml and application.yaml are recognised. When the same key appears in more than one location, the higher-precedence location wins.
#1 Best Overall
Changing the default locations
spring.config.locationreplaces the default search locations.spring.config.additional-locationadds locations on top of the defaults.
Both properties are set outside the file they affect, typically on the command line or as an environment variable, because they are resolved before the file is read.
Profile-specific files
A profile-specific file such as application-prod.yml supplements the base application.yml when its profile is active. Profiles are activated with spring.profiles.active. For a key defined in both files, the profile-specific value wins, because the profile document is applied on top of the base document. Profile ordering and location groups can change which profile file wins when several are active.
Imports with spring.config.import
Configuration can bring in further documents with spring.config.import:
spring:
config:
import: "optional:file:./local-overrides.yml"
An imported document is treated as sitting beneath the document that declares the import, and it can override values from that declaring document. The optional: prefix lets startup continue when the location does not exist. Without it, a missing import fails startup.
Why a value is not what you wrote in application.yml
When a value differs from the one in the base file, check the following axes in order. Each one can override the others.
| Axis | What to check | Why it matters |
|---|---|---|
| Property-source type and precedence | Command-line arguments, environment variables, Java system properties, and the other sources in the precedence list | Higher-precedence sources override any file value with the same key |
| Base versus profile-specific document | Whether application-{profile}.yml exists and its profile is active |
The profile document overrides the base file |
| Import versus declaring document | Any spring.config.import entries in the file that declares the value |
An imported document can override the declaring document |
| Location and location-group ordering | Which of the default locations contain a file with the same name | A higher location shadows a lower one for the same key |
| Spring Boot release | The exact version in your build file | Locations, defaults, and precedence are documented per release line |
Common causes
- An environment variable such as
SERVER_PORTset on the host or in the container overridesserver.portin the file. - A second
application.ymlin./config/shadows the one packaged inside the JAR. - A profile file defines the same key, and the profile is active in one environment but not in another.
- An imported file declares a key that the declaring file also defines, and the import wins.
Custom property sources and timing
The Spring Boot how-to guide for custom EnvironmentPostProcessor implementations explains that the usual property sources are available by the time an EnvironmentPostProcessor runs. It also warns against relying on @PropertySource for early settings. The guide states: “Such property sources are not added to the Environment until the application context is being refreshed.” This means that @PropertySource is too late for early-read properties such as logging.* and spring.main.*. If you need a custom source that those settings can see, register it through an EnvironmentPostProcessor instead.
Rank #4
How to see which value wins
- Add
spring-boot-starter-actuatorto the build. - Expose the endpoint by setting
management.endpoints.web.exposure.include=env. - Open
/actuator/envand search for the key. The response lists each property source in order, with the value it contributed. - Find the highest-precedence source that defines the key. That source is the one the bean receives.
Expose the Actuator endpoint only in environments where that is appropriate, because it reveals configuration values.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Version notes
The mechanics described here apply to Spring Boot 2.4.0 and later, when the ConfigData model and ConfigDataEnvironmentPostProcessor were introduced. The reference material used for this article covers Spring Boot 3.3 (Externalized Configuration) and 3.5 (Properties and Configuration), and the API page cited is for 3.5.14. For a specific application, confirm the default locations and precedence in the reference for your own Spring Boot version before relying on an exact order.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
