EnvironmentPostProcessor SPI

## The registration mechanism: spring.factories Because an `EnvironmentPostProcessor` runs **before the ApplicationContext exists**, Spring can't find it by scanning for annotations — component scanning is a context-time activity. Instead Boot uses the older **`spring.factories`** discovery mechanism (`SpringFactoriesLoader`), which reads plain text files off the classpath at `META-INF/spring.factories`. You add an entry keyed by the SPI interface's fully-qualified name: ``` org.springframework.boot.env.EnvironmentPostProcessor=\ com.example.DefaultsEnvironmentPostProcessor,\ com.example.SecretsEnvironmentPostProcessor ``` The value is a comma-separated list of your implementation classes (backslash lets you wrap lines). Spring Boot reads **all** such files from **every** jar on the classpath and aggregates the implementations — that's how starters ship their own EPPs. ## What actually loads them Inside Boot, `EnvironmentPostProcessorApplicationListener` listens for `ApplicationEnvironmentPreparedEvent`. When it fires, it asks an `EnvironmentPostProcessorsFactory` (built from `spring.factories` via `EnvironmentPostProcessorsFactory.fromSpringFactories(...)`) to instantiate the classes, then calls `postProcessEnvironment(...)` on each in order. ## Why NOT @Component - No `ApplicationContext` yet → no `BeanFactory` → nothing to register beans in. - Component scanning is triggered during context refresh, long after the Environment is prepared. - If you annotate it `@Component`, Spring will happily create it *as a bean* later, but it will **never call `postProcessEnvironment`** for that purpose, so it silently does nothing useful for environment mutation. ## The big gotcha: it is NOT AutoConfiguration.imports Since Spring Boot 2.7, **auto-configuration classes** (`@AutoConfiguration`) are listed in `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`, replacing the old `EnableAutoConfiguration` key in `spring.factories`. People conflate the two, but: - `AutoConfiguration.imports` → only for `@AutoConfiguration` classes → runs during **context refresh**, after the Environment is finalized. - `EnvironmentPostProcessor` → still uses **`spring.factories`** → runs during **environment preparation**. Putting an EPP in `AutoConfiguration.imports` does nothing; putting an auto-config in the EPP key does nothing. ## Constructor injection of a few special types An EPP is instantiated by reflection, but Boot does allow a constructor that accepts a small fixed set of types it can supply itself — notably `DeferredLogFactory`, `org.apache.commons.logging.Log`, and `ConfigurableBootstrapContext`/`BootstrapContext`/`BootstrapRegistry`. This is not general DI; it's a hard-coded convenience for deferred logging and bootstrap context sharing (see the logging question). ## Ordering across multiple EPPs When several are registered, control order by implementing `Ordered` or annotating with `@Order` (lower value = earlier). Boot's own `ConfigDataEnvironmentPostProcessor` sits near the top of precedence.