Before delving into the details of an external configuration setup, let's quickly look at the code that was added in order to print the property value in the log. The element of focus is the @Value annotation that can be used on class fields or method arguments; it also instructs Spring to automatically inject the annotated variable with the value defined in the annotation. If the value is positioned in the wrapping curly braces prefixed with a dollar sign, (${ }), Spring will replace this with the value from the corresponding application property or with the default value, if it is provided, by adding the textual data after the colon (:).

In our case, we defined it as @Value("${my.config.value:}")String configValue, so unless an application property named my.config.value exists, the default value of an empty String will be assigned to the configValue method argument. This construct is quite handy and eliminates the need to explicitly wire in the instance of an environment object just to get a specific property value out of it, as well as simplifying the code during testing, with less objects to mock.

The support for being able to specify the location of the application properties configuration file is geared towards supporting a dynamic multitude of environmental topologies, especially in cloud environments. This is often the case when the compiled application gets bundled into different cloud images that are destined for different environments and are being specially assembled by deployment tools such as Packer, Vagrant, and others.

In this scenario, it is very common to drop a configuration file in the image filesystem while making the image, depending on what environment it is destined for. Spring Boot provides a very convenient ability to specify, via the command-line arguments, where the configuration properties file, which should be added to the application configuration bundle, resides.

Using the --spring.config.location startup option, we can specify a location of one or multiple files, which can then be separated by a comma (,) to be added to the default ones. The file designations can be either files from a local filesystem, a classpath, or a remote URL. The locations will be resolved either by the DefaultResourceLoader class or, if configured via a SpringApplication constructor or setter, by the implementation that is provided by the SpringApplication instance.

If the location contains directories, the names should end with a / so as to let Spring Boot know that it should look for the application.properties file in these directories.

If you want to change the default name of the file, Spring Boot provides you with this ability as well. Just set the --spring.config.name option to whatever filename that you want.