EnvironmentPostProcessor in Spring Boot

1. Overview

As of Spring Boot 1.3, we’re able to use the EnvironmentPostProcessor to customize the application’s Environment before application context is refreshed.

In this tutorial, let’s take a look at how to load and transform the custom properties into the Environment, and then access those properties.

2. Spring Environment

The Environment abstraction in Spring represents the environment in which the current application is running.  In the meanwhile, it tends to unify the ways to access properties in a variety of property sources, such as properties files, JVM system properties, system environment variables, and servlet context parameters.

So in most cases, customizing the Environment means manipulation of various properties before they’re exposed to our beans. To start, please visit our previous article on manipulating properties with Spring.

3. A Quick Example

Let’s now build a simple price calculation application. It’ll calculate the price in either gross-based or net-based mode. The system environment variables from a third party will determine which calculation mode to choose.

3.1. Implementing EnvironmentPostProcessor

To do this, let’s implement the EnvironmentPostProcessor interface.

We’ll use it to read a couple of environment variables:

calculation_mode=GROSS 
gross_calculation_tax_rate=0.15

And we’ll use the post-processor to expose these in an application-specific way, in this case with a custom prefix:

com.baeldung.environmentpostprocessor.calculation.mode=GROSS
com.baeldung.environmentpostprocessor.gross.calculation.tax.rate=0.15

Then, we can quite simply add our new properties into the Environment:

@Order(Ordered.LOWEST_PRECEDENCE)
public class PriceCalculationEnvironmentPostProcessor implements EnvironmentPostProcessor {

    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, 
      SpringApplication application) {
        PropertySource<?> system = environment.getPropertySources()
          .get(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME);
        if (!hasOurPriceProperties(system)) {
          // error handling code omitted
        }
        Map<String, Object> prefixed = names.stream()
          .collect(Collectors.toMap(this::rename, system::getProperty));
        environment.getPropertySources()
          .addAfter(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, new MapPropertySource("prefixer", prefixed));
    }

}

Let’s see what we’ve done here. First, we asked environment to give us the PropertySource for environment variables. Calling the resulting system.getProperty is similar to calling Java’s System.getenv().get.

Then, so long as those properties exist in the environment, we’ll create a new map, prefixed. For brevity, we’ll skip the contents of rename, but check out the code sample for the complete implementation. The resulting map has the same values as system, but with prefixed keys.

Finally, we’ll add our new PropertySource to the Environment. Now, if a bean asks for com.baeldung.environmentpostprocessor.calculation.mode, the Environment will consult our map.

Note, by the way, that EnvironmentPostProcessor‘s Javadoc encourages us to either implement the Ordered interface or use the @Order annotation.

And this is, of course, just a single property source. Spring Boot allows us to cater to numerous sources and formats.

3.2. Registration in the spring.factories

To invoke the implementation in the Spring Boot bootstrap process, we need to register the class in the META-INF/spring.factories:

org.springframework.boot.env.EnvironmentPostProcessor=
  com.baeldung.environmentpostprocessor.PriceCalculationEnvironmentPostProcessor

3.3. Access the Properties Using @Value Annotation

Let’s use these in a couple of classes. In the sample, we’ve got a PriceCalculator interface with two implementations: GrossPriceCalculator and NetPriceCalculator.

In our implementations, we can just use @Value to retrieve our new properties:

public class GrossPriceCalculator implements PriceCalculator {
    @Value("${com.baeldung.environmentpostprocessor.gross.calculation.tax.rate}")
    double taxRate;

    @Override
    public double calculate(double singlePrice, int quantity) {
        //calcuation implementation omitted
    }
}

This is nice as it’s the same way we access any other properties, like those we’ve defined in application.properties.

3.4. Access the Properties in Spring Boot Auto-configuration

Now, let’s see a complex case where we access the preceding properties in Spring Boot autoconfiguration.

We’ll create the autoconfiguration class to read those properties. This class will initialize and wire the beans in the application context according to the different property values:

@Configuration
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
public class PriceCalculationAutoConfig {
    @Bean
    @ConditionalOnProperty(name = 
      "com.baeldung.environmentpostprocessor.calculation.mode", havingValue = "NET")
    @ConditionalOnMissingBean
    public PriceCalculator getNetPriceCalculator() {
        return new NetPriceCalculator();
    }

    @Bean
    @ConditionalOnProperty(name = 
      "com.baeldung.environmentpostprocessor.calculation.mode", havingValue = "GROSS")
    @ConditionalOnMissingBean
    public PriceCalculator getGrossPriceCalculator() {
        return new GrossPriceCalculator();
    }
}

Similar to the EnvironmentPostProcessor implementation, the autoconfiguration class needs to be registered in the META-INF/spring.factories as well:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=
  com.baeldung.environmentpostprocessor.autoconfig.PriceCalculationAutoConfig

This works because custom EnvironmentPostProcessor implementations kick in before Spring Boot autoconfiguration does. This combination makes Spring Boot autoconfiguration more powerful.

And, for more specifics about Spring Boot autoconfiguration, please have a look at the article on Custom Auto-Configuration with Spring Boot.

4. Test the Custom Implementation

Now it’s time to test our code. We can set the system environment variables in Windows by running:

set calculation_mode=GROSS
set gross_calculation_tax_rate=0.15

Or in Linux/Unix, we can export them instead:

export calculation_mode=GROSS 
export gross_calculation_tax_rate=0.15

After that, we could start the test with the mvn spring-boot:run command:

mvn spring-boot:run
  -Dstart-class=com.baeldung.environmentpostprocessor.PriceCalculationApplication
  -Dspring-boot.run.arguments="100,4"

5. Conclusion

To sum up, the EnvironmentPostProcessor implementation is able to load arbitrary files in a variety of formats from different locations. In addition, we can do any transformation we need to make the properties readily available in the Environment for later use. This freedom is certainly useful when we integrate Spring Boot-based application with the third-party configurations.