Infinite loop caused by import of XML configuration that declares a ConfigurationClassPostProcessor [SPR-11858]

[spring-projects-issues]

Andy Wilkinson opened SPR-11858 and commented

A @Configuration class that uses @ImportResource to pull in XML configuration that declares a ConfigurationClassPostProcessor causes an infinite loop.

This:

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.ImportResource;

@Configuration
@ImportResource(value = "application-context.xml")
public class Application {

	public static void main(String[] args) {
		new AnnotationConfigApplicationContext(Application.class);
	}
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
		http://www.springframework.org/schema/beans/spring-beans-4.0.xsd">
	
	<bean class="org.springframework.context.annotation.ConfigurationClassPostProcessor"/>

</beans>

Results in the bean definitions from application-context.xml being loaded repeatedly:

INFO: Loading XML bean definitions from class path resource [application-context.xml]
Jun 9, 2014 11:13:01 AM org.springframework.beans.factory.support.DefaultListableBeanFactory registerBeanDefinition
INFO: Overriding bean definition for bean 'org.springframework.context.annotation.ConfigurationClassPostProcessor.importAwareProcessor': replacing [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] with [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null]
Jun 9, 2014 11:13:01 AM org.springframework.beans.factory.support.DefaultListableBeanFactory registerBeanDefinition
INFO: Overriding bean definition for bean 'org.springframework.context.annotation.ConfigurationClassPostProcessor.enhancedConfigurationProcessor': replacing [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$EnhancedConfigurationBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] with [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$EnhancedConfigurationBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null]
Jun 9, 2014 11:13:01 AM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [application-context.xml]
Jun 9, 2014 11:13:01 AM org.springframework.beans.factory.support.DefaultListableBeanFactory registerBeanDefinition
INFO: Overriding bean definition for bean 'org.springframework.context.annotation.ConfigurationClassPostProcessor.importAwareProcessor': replacing [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] with [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null]
Jun 9, 2014 11:13:01 AM org.springframework.beans.factory.support.DefaultListableBeanFactory registerBeanDefinition
INFO: Overriding bean definition for bean 'org.springframework.context.annotation.ConfigurationClassPostProcessor.enhancedConfigurationProcessor': replacing [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$EnhancedConfigurationBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] with [Root bean: class [org.springframework.context.annotation.ConfigurationClassPostProcessor$EnhancedConfigurationBeanPostProcessor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null]
Jun 9, 2014 11:13:01 AM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
…

The problem is a regression introduced in 4.0.0. The infinite loop does not occur when testing with 3.2.x

---

Affects: 4.0.5

Issue Links:

• Allow BeanDefinitionRegistryPostProcessor to register other BeanDefinitionRegistryPostProcessors [SPR-10630] #15258 Allow BeanDefinitionRegistryPostProcessor to register other BeanDefinitionRegistryPostProcessors

Referenced from: commits 7b38b41, b625512

[spring-projects-issues]

Dave Syer commented

I would hope that adding a bean of type ConfigurationClassPostProcessor would be uncommon, or maybe even forbidden?. Neo4j does it here https://github.com/spring-projects/spring-data-neo4j/blob/master/spring-data-neo4j/src/main/java/org/springframework/data/neo4j/config/DataGraphBeanDefinitionParser.java#L98 (which is how we discovered this issue in a Boot app). Maybe they need to add it conditionally? Neo4j issue: spring-projects/spring-data-neo4j#190.

[spring-projects-issues]

Juergen Hoeller commented

We should at least try to detect that case and prevent the infinite loop...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

The specific problem here is the use of generated bean names for a BeanDefinitionRegistryPostProcessor bean, as with <bean class="..."/> entries or also programmatically as in Neo4j's DataGraphBeanDefinitionParser... This leads to runaway reiteration of BeanDefinitionRegistryPostProcessor detection (see #15258), since every postProcessBeanDefinitionRegistry invocation leads to yet another BeanDefinitionRegistryPostProcessor bean appearing in the context, with a new generated bean name...

That said, it's generally not advisable to declare a manual ConfigurationClassPostProcessor bean. Such a definition only makes sense in a user-specific configuration arrangement if it's clear that there's no auto-registration of post-processors configured next to it. In a BeanDefinitionParser, I'd consider it forbidden... If at all, they'd have to call AnnotationConfigUtils.registerAnnotationConfigProcessors in order to reuse the canonical bean names for the common post-processors, but even that I wouldn't recommend.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

ConfigurationClassPostProcessor skips pre-processed bean definitions now, avoiding side effects in case of multiple CCPPs such as the scenario above. We will still call each of those CCPPs but only the first one is going to actually process any given configuration class now.

Juergen