title: Why is Spring 4.0.9 applicationContext initialization getting stuck but not 3.2.1?
body: <p>My applicationContext initialization was working fine with Spring 3.2.1. </p>
  
  <p>But when I upgraded to 4.0.9 without changing any code or bean definitions), the initialization got stuck. The following statement kept on happening. There's no  obvious circular reference though.</p>
  
  <pre><code>Requested bean is currently in creation: Is there an unresolvable circular reference?
  </code></pre>
  
  <p>I continued to investigate. I deliberately removed a bean definition. </p>
  
  <ul>
  <li>Spring 3.2.1 had the expected outcome: threw a fatal error almost immediately.</li>
  <li>Spring 4.0.9 was still getting into this infinite loop, trying to find a different seed bean definition to make things work. </li>
  </ul>
  
  <p>Here's the log statement that kept on happening. </p>
  
  <pre><code>[factory.support.DefaultListableBeanFactory.getTypeForFactoryBean()] - Ignoring bean creation exception on FactoryBean type check:
  org.springframework.beans.factory.BeanCreationException: 
  Error creating bean with name 'someSeedBean-which-is-different-in-every-instance-of-this-log' defined in the class path resource ........ ; 
  nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'someDataSource' is defined 
  </code></pre>
  
  <p>What's changed? Any ideas would be helpful.</p>
  
  <hr>
  
  <p>Bean definitions that work in both Spring 3.x and 4.x</p>
  
  <pre><code>&lt;bean id="abstractDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
          destroy-method="close" abstract="true" scope="singleton"&gt;
          &lt;property ....&gt;
  &lt;/bean&gt;
  
  &lt;bean id="someDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
          destroy-method="close" scope="singleton" parent="abstractDataSource"&gt;
          &lt;property name="driverClass" .... /&gt;   
  &lt;/bean&gt;
  
  &lt;bean id="someSessionFactory"
      class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"&gt;
      &lt;property name="dataSource"&gt; &lt;ref bean="someDataSource" /&gt;  &lt;/property&gt;
      &lt;property name="packagesToScan"&gt; &lt;list&gt;......&lt;/list&gt; &lt;/property&gt;
      ....
  </code></pre>
  
  <p> </p>
  
  <p>Bean definitions that work in Spring 3.x but not in 4.0.9.</p>
  
  <pre><code>@Configuration
  public class SomeSpringConfiguration{
  
      // Moving this beanDef to Java for features not available in XML
      @Bean(destroyMethod = "close")
      public DataSource someDataSource() { // also tried setting this to ComboPooledDataSource
          // verified that this beanDefinition is recognized by Spring
          // but this bean is never created / this method is never executed
          ...
          return datasource;
      }
  }     
  
  &lt;bean class="SomeSpringConfiguration" /&gt;
  
  &lt;bean id="someSessionFactory"
      class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"&gt;
      &lt;property name="dataSource"&gt; &lt;ref bean="someDataSource" /&gt;  &lt;/property&gt;
      &lt;property name="packagesToScan"&gt; &lt;list&gt;......&lt;/list&gt; &lt;/property&gt;
      ....
  &lt;/bean&gt;   
  </code></pre>
  
  <p>Error I get with Spring 4.0.9 is</p>
  
  <pre><code>Cannot resolve reference to bean 'someSessionFactory' while setting constructor argument; 
  nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: 
  Error creating bean with name 'someSessionFactory': 
  Requested bean is currently in creation: Is there an unresolvable circular reference?
  </code></pre>
  
  <p>Please note that the application has thousands of beans defined in/via xml, @Component, and @Configuration. I had to move above bean from xml to a @Configuration class to execute a complicated bean build procedure.</p>
  
  <p>-----------------------UPDATE</p>
  
  <p>I found the issue: 'tons of MethodInvokingFactoryBean[MIB] usages'. For some reason, Spring 4 was getting confused in presence of tons of MIBs. The exact same code base worked fine with Spring 3. I migrated all the logic performed by various MIBs to an ApplicationListener. Please note that ApplicationListener is not an intended replacement for MIBs but in my case I could reproduce the logic in a listener because the MIBs were just performing static injection of Spring beans into classes not managed by Spring. It not only fixed this issue but decreased Spring startup time to ~200 seconds from ~300 seconds.</p>
  
  <p>Unfortunately, I neither could figure out the root cause in Spring nor could reproduce the issue in a smaller code-base (to share here).</p>