In this recipe, we have explored how to add our own custom PropertySource that allowed us to bridge the existing system in the Spring Boot environment. Let's look into the inner workings of how the pieces fit together.

In the previous section, we learned how the different configuration definitions stacked up and what rules were used to overlay them on top of each other. This will help us to better understand how the bridging of an Apache Commons Configuration, using a custom PropertySource implementation, works. (This should not be confused with an @PropertySource annotation!)

In Chapter 4, Writing Custom Spring Boot Starters, we learned about the use of spring.factories, and so we already know that this file serves to define the classes that should automatically be incorporated by Spring Boot during application startup. The only difference this time is that instead of configuring the EnableAutoConfiguration settings, we will configure the SpringApplicationRunListener ones.

We created the following two classes to support our needs:

• ApacheCommonsConfigurationPropertySource: This is the extension of the EnumerablePropertySource base class that provides you with internal functionality in order to bridge XMLConfiguration from Apache Commons Configuration to the world of Spring Boot by providing transformation to get the specific property values by name via the getProperty(String name) implementation, and the list of all the supported property names via the getPropertyNames() implementation. In situations where you are dealing with the use case when the complete list of the available property names is not known or is very expensive to compute, you can just extend the PropertySource abstract class instead of using EnumerablePropertySource.
• ApacheCommonsConfigurationEnvironmentPostProcessor: This is the implementation of the EnvironmentPostProcessor interface that gets instantiated by Spring Boot during the application startup and receives notification callback after the initial environment initialization has been completed, but before the application context startup. This class is configured in spring.factories and is automatically created by Spring Boot.

In our post-processor, we implement the postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) method, which gives us access to the ConfigurableEnvironment instance. By the time this callback is invoked, we will get an environment instance that has already been populated with all of the properties from the preceding hierarchy. However, we will get the opportunity to inject our own PropertySource implementation anywhere in the list, which we will successfully do in the ApacheCommonsConfigurationPropertySource.addToEnvironment(...) method.

In our case, we will choose to insert our source right below systemEnvironment in the order of precedence, but if needs be, we can alter this order to whatever highest precedence we desire. Just be careful not to place it so high that your properties become impossible to override via the command-line arguments, system properties, or environment variables.