Most Spring developers know about the BeanPostProcessor and the BeanFactoryPostProcessor classes. The former enables changes to new bean instances before they can be used, while the latter lets you modify bean definitions - the metadata to create the bean. Commons use-cases include:

Bootstrapping processing of @Configuration classes, via ConfigurationClassPostProcessor

Resolving ${…​} placeholders, through PropertyPlaceholderConfigurer

Autowiring of annotated fields, setter methods and arbitrary config methods - AutowiredAnnotationBeanPostProcessor

And so on, and so forth…​

Out-of-the-box and custom post-processors are enough to meet most requirements regarding the Spring Framework proper.

Then comes Spring Boot, with its convention over configuration approach. Among its key features is the ability to read configuration from different sources such as the default application.properties , the default application.yml , another configuration file and/or System properties passed on the command line. What happens behind the scene is that they all are merged into an Environment instance. This object can then be injected into any bean and queried for any value by passing the key.

As a starter designer, how to define a default configuration value? Obviously, it cannot be set via a Spring @Bean -annotated method. Let’s analyze the Spring Cloud Sleuth starter as an example:

Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing heavily from Dapper, Zipkin and HTrace. For most users Sleuth should be invisible, and all your interactions with external systems should be instrumented automatically. You can capture data simply in logs, or by sending it to a remote collector service.

Regarding the configuration, the starter changes the default log format to display additional information (to be specific, span and trace IDs but that’s not relevant to the post). Let’s dig further.

As for auto-configuration classes, the magic starts in the META-INF/spring.factories file in the Spring Cloud Sleuth starter JAR:

# Environment Post Processor org.springframework.boot.env.EnvironmentPostProcessor=\ org.springframework.cloud.sleuth.autoconfig.TraceEnvironmentPostProcessor

The definition of the interface looks like the following:

public interface EnvironmentPostProcessor { void postProcessEnvironment ( ConfigurableEnvironment environment , SpringApplication application ); }

And the implementation like that:

public class TraceEnvironmentPostProcessor implements EnvironmentPostProcessor { private static final String PROPERTY_SOURCE_NAME = "defaultProperties" ; @Override public void postProcessEnvironment ( ConfigurableEnvironment environment , SpringApplication application ) { Map < String , Object > map = new HashMap < String , Object >(); map . put ( "logging.pattern.level" , "%clr(%5p) %clr([${spring.application.name:},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}]){yellow}" ); map . put ( "spring.aop.proxyTargetClass" , "true" ); addOrReplace ( environment . getPropertySources (), map ); } private void addOrReplace ( MutablePropertySources propertySources , Map < String , Object > map ) { MapPropertySource target = null ; if ( propertySources . contains ( PROPERTY_SOURCE_NAME )) { PropertySource <?> source = propertySources . get ( PROPERTY_SOURCE_NAME ); if ( source instanceof MapPropertySource ) { target = ( MapPropertySource ) source ; for ( String key : map . keySet ()) { if (! target . containsProperty ( key )) { target . getSource (). put ( key , map . get ( key )); } } } } if ( target == null ) { target = new MapPropertySource ( PROPERTY_SOURCE_NAME , map ); } if (! propertySources . contains ( PROPERTY_SOURCE_NAME )) { propertySources . addLast ( target ); } } }

As can be seen, the implementation will add both the logging.pattern.level and the spring.aop.proxyTargetClass properties (with relevant values) to the environment (if they don’t exist yet). If they do, they will be added at the bottom of the list.