Spring Boot uses a very particular PropertySource order that is designed to allow sensible overriding of values. Properties are considered in the following order (with values from lower items overriding earlier ones):

1. Default properties (specified by setting SpringApplication.setDefaultProperties).
2. @PropertySource annotations on your @Configuration classes. Please note that such property sources are not added to the Environment until the application context is being refreshed. This is too late to configure certain properties such as logging.* and spring.main.* which are read before refresh begins.
3. Config data (such as application.properties files).
1. Application properties packaged inside your jar (application.properties and YAML variants).
2. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants).
3. Application properties outside of your packaged jar (application.properties and YAML variants).
4. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants).
4. A RandomValuePropertySource that has properties only in random.*.
5. OS environment variables.
6. Java System properties (System.getProperties()).
7. JNDI attributes from java:comp/env.
8. ServletContext init parameters.
9. ServletConfig init parameters.
10. Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable or system property).
11. Command line arguments.
12. properties attribute on your tests. Available on @SpringBootTest and the test annotations for testing a particular slice of your application.
13. @TestPropertySource annotations on your tests.
14. Devtools global settings properties in the \$HOME/.config/spring-boot directory when devtools is active.

Config data

Specify a default configuration file

spring.config.location: specify a default configuration file path or directory

spring.config.additional-location: additional configuration file that will override default configuration file

Program arguments

System Properties (VM Arguments)

application.properties

OS Environment Variables

On Windows, if you add new OS Environment Variables, you must to restart process (Java process, Intellij IDEA) to read the new OS Environment Variables.

Any other Windows executable, system-level changes to the environment variables are only propagated to the process when it is restarted.

Add User variables or System variables on Linux or Windows

1. Injecting environment variables
1. Setting application.properties values from environment

JSON Application Properties

Environment variables and system properties often have restrictions that mean some property names cannot be used. To help with this, Spring Boot allows you to encode a block of properties into a single JSON structure.

When your application starts, any spring.application.json or SPRING_APPLICATION_JSON properties will be parsed and added to the Environment.

For example, the SPRING_APPLICATION_JSON property can be supplied on the command line in a UN*X shell as an environment variable:

In the preceding example, you end up with my.name=test in the Spring Environment.

The same JSON can also be provided as a system property:

Or you could supply the JSON by using a command line argument:

If you are deploying to a classic Application Server, you could also use a JNDI variable named java:comp/env/spring.application.json.

Accessing Command Line Properties

By default, SpringApplication converts any command line option arguments (that is, arguments starting with --, such as --server.port=9000) to a property and adds them to the Spring Environment. As mentioned previously, command line properties always take precedence over file-based property sources.

If you do not want command line properties to be added to the Environment, you can disable them by using SpringApplication.setAddCommandLineProperties(false).

Maven Command with application arguments:

java -jar with System Properties (VM Arguments)

java -jar with Program Arguments