Regression in @Condition exclusion [SPR-12233]

[spring-projects-issues]

Christopher Smith opened SPR-12233 and commented

I have a bean that's doing conditional autoconfiguration based on whether a certain property is available in the environment; the actual condition matcher is

@Override
public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
	return context.getEnvironment().containsProperty(POSTBACK_URL_PROPERTY);
}

The configuration class then creates a bean using an @Value injection if that property is present.

Spring 4.0.7->4.1.0 introduced a regression wherein the @Value is being evaluated even when the @Condition should not match, causing the context startup to crash. I have debugged, and Spring is in fact running the condition's matcher before proceeding to try (and fail) to extract the property from the environment. I attempted to step through it, but I could not tell whether the environment is erroneously returning true from containsProperty or the DI container is failing to disable the class when it has a false condition.

A simple Spring Boot application demonstrating the behavior is available at the GitHub link. Change the Spring version in the POM to 4.1.0 to demonstrate the bug; the launcher will crash on startup.

---

Affects: 4.1 GA

Reference URL: https://github.com/chrylis/spring-SPR-12233

Issue Links:

• Spring may invoke @Bean methods too early in case of a circular reference [SPR-12018] #16634 Spring may invoke @Bean methods too early in case of a circular reference
• @Configuration imported via @ImportResource is not processed [SPR-11723] #16345 @Configuration imported via @ImportResource is not processed

Referenced from: commits 4c59d85

[spring-projects-issues]

Christopher Smith commented

I'm also seeing this behavior (exceptions on refreshing the context) when JRebel tries to reload under 4.0.7. The underlying regression may actually be in 4.0.7 (perhaps the changes related to #16634?), and 4.1.0 just triggers it earlier.

[spring-projects-issues]

Phil Webb commented

Thanks for the detailed report and for the sample project. There was very specific set of circumstances needed to trigger the bug.

[spring-projects-issues]

Christopher Smith commented

I have updated to 4.1.1 and am seeing the same issue. The actual environment in which I'm seeing the behavior is a JRebel context reload after modifying a controller class. The exception is occurring in the actual library I used in the example (the Blitline Java client Spring connector) because an optional environment property is not present, but the DI is trying to instantiate the bean anyway.

Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'blitline.postbackUrl' in string value "${blitline.postbackUrl}"
	at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174)
	at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126)
	at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:204)
	at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:178)
	at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$2.resolveStringValue(PropertySourcesPlaceholderConfigurer.java:175)
	at org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(AbstractBeanFactory.java:800)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:917)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:904)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:527)

[spring-projects-issues]

Phil Webb commented

Christopher Smith Are you able to reproduce the issue without JRebel?

[spring-projects-issues]

Christopher Smith commented

I'm not sure how to. It seems to be related to refreshing the ApplicationContext, as that was where the bug triggered in 4.0.7 and 4.1.0 with just Spring Boot. I can try seeing if I can modify my test case to make it happen. What's the simplest way of getting the context in a Spring Boot one-shot? ApplicationContextAware controller?

[spring-projects-issues]

Phil Webb commented

The context is returned from SpringApplication.run so you can probably just grab it directly from that.

[spring-projects-issues]

Christopher Smith commented

Attempts to call refresh() on that context give me an IllegalStateException saying I can only refresh once. I can reliably reproduce by having JRebel reload a class that requires a context reconfig.

[spring-projects-issues]

Phil Webb commented

Christopher Smith Could you please open a new issue for this. It sounds like it's something specific to the way that JRebel is interacting with Spring.