EnvironmentPostProcessor implementations are not invoked at build-time

[bdemers]

Conditional beans whose properties are defined by an EnvironmentPostProcessor are not available.

For example, if I create a EnvironmentPostProcessor that adds a PropertySource containing the property foo:

public class CustomEnvPostProcessor implements EnvironmentPostProcessor {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        environment.getPropertySources().addLast(new MapPropertySource("example", Map.of("foo", "bar")));
    }
}

Beans dependent on this property such as:

@Bean
@ConditionalOnProperty(name="foo")
Bar bar() {
  return new Bar();
}

Will not be available, and will throw a NoSuchBeanDefinitionException exception at runtime.

Injecting the property with a @Value annotation seems to work without issue.

Example repo demonstrating the problem: https://github.com/bdemers/spring-native-aot-problem

NOTE: The example above works when the native plugins are disabled

[snicoll]

Thanks for the sample. AotApplicationContextFactory does not invoke EnvPP when preparing the environment at build-time. I don't remember why that is or what was the constraints. Do you @bclozel?

[bclozel]

@snicoll I don't know if we wanted to start with something minimal there and never got to this use case, or if there were concerns about EnvPP instances doing "clever" things that could be incompatible with build time processing. In any case I think we can try and fix this issue.

[snicoll]

We've been discussing this one and it's a tough call at this stage. Our preparation of the environment is pretty basic as we don't really have a way to distinguish build-time vs. runtime processing of the environment. Until that's the case, I think it's wiser to move this one to backlog.

[mraible]

Are there any updates on this? As things currently stand, the Okta Spring Boot starter does not work in native mode because of this problem. Which is unfortunate, because it did work in previous versions.

[snicoll]

@mraible It's in the backlog so I am afraid we have no plan to fix this in Spring Native itself. We'll pick this up in Spring Boot 3.

[sdeleuze]

Spring Native is now superseded by Spring Boot 3 official native support, see the related reference documentation for more details.

As a consequence, I am closing this issue, and recommend trying your use case with latest Spring Boot 3 version. If you still experience the issue reported here, please open an issue directly on the related Spring project (Spring Framework, Data, Security, Boot, Cloud, etc.) with a reproducer.

Thanks for your contribution on the experimental Spring Native project, we hope you will enjoy the official native support introduced by Spring Boot 3.