title: Why does Spring get circular dependency issues on one machine and not another?
body: <p>I have a problem getting a Spring Data based application to run in my environment. I am running Debian, but my co-workers are either using Mac or Ubuntu. I have nothing special set up in my environment variables, and am using the exact same version of Java as others.</p>
  
  <p>I have seen this in the logs, suggesting that it is a circular reference problem that is leading to the instantiation failure:</p>
  
  <pre><code>nested exception is
  org.springframework.beans.factory.BeanCreationException: Error
  creating bean with name 'flyway.CONFIGURATION_PROPERTIES':
  Initialization of bean failed;
  ...
  nested exception is
  org.springframework.beans.factory.BeanCurrentlyInCreationException:
  Error creating bean with name 'flyway': Requested bean is currently in
  creation: Is there an unresolvable circular reference?
  </code></pre>
  
  <p>So the problem appears to be that flyway needs some dependencies and they need flyway. </p>
  
  <p>The question is, why does this only happen on my environment not anyone elses? Even on the tests using H2 in memory, I see the problem, so its not my database that is at fault.</p>
  
  <p>Is it possible that Spring autowiring is confused somehow, and tries to do things in the wrong order, so that the repository is null when it tries to set it?</p>
  
  <p>Does Spring have a badly implemented topological sort for ordering dependencies? </p>
  
  <p>Why would it misbehave on my environment? </p>
  
  <p>Could ordering of the classpath influence its behaviour?</p>
  
  <p>======================</p>
  
  <p>The application will not start with this error:</p>
  
  <pre><code>Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'contentItemRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: Repository interface must not be null on initialization!
      at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
      at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:127)
      at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1517)
      at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:251)
      at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
      at org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1127)
  </code></pre>
  
  <p>============================</p>
  
  <p>The ContentItemRepository signature is:</p>
  
  <pre><code>@Repository
  @Transactional
  public interface ContentItemRepository extends JpaRepository&lt;ContentItem, String&gt;, JpaSpecificationExecutor&lt;ContentItem&gt; {
  </code></pre>
  
  <p>============================</p>
  
  <p>This used to work for me, and I was able to identify the commit that broke the build, by iterating through all commits, doing a mvn clean install, and trying to start the server, until I found the delta that broke it.</p>
  
  <p>The 'contentItemRepository' that cannot be null is this one:</p>
  
  <pre><code>@Component
  +public class UrlAliasRequestConverter implements Mapper&lt;UrlAliasRequest, UrlAlias&gt; {
  +
  +    /**
  +     * The content item contentItemType repository.
  +     */
  +    @Autowired
  +    private ContentItemRepository contentItemRepository;
  </code></pre>