为什么Spring在一台机器而不是另一台机器上获得循环依赖性问题？

Question

我在使用基于Spring Data的应用程序在我的环境中运行时遇到了问题.我正在运行Debian,但我的同事正在使用Mac或Ubuntu.我的环境变量中没有任何特殊设置,并且使用与其他版本完全相同的Java版本.

我在日志中看到过这一点,这表明它是一个循环引用问题导致实例化失败:

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?

所以问题似乎是飞路需要一些依赖,他们需要飞路.

问题是,为什么这只发生在我的环境而不是任何人？即使在内存中使用H2的测试中,我也看到了问题,因此不是我的数据库出错了.

是否有可能以某种方式混淆Spring自动装配,并尝试以错误的顺序执行操作,以便在尝试设置存储库时为null？

Spring是否有一个严重实现的拓扑排序用于排序依赖项？

为什么它会对我的环境造成不良影响？

类路径的排序会影响它的行为吗？

======================

应用程序不会以此错误开头:

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)

============================

ContentItemRepository签名是:

@Repository
@Transactional
public interface ContentItemRepository extends JpaRepository<ContentItem, String>, JpaSpecificationExecutor<ContentItem> {

============================

这曾经为我工作,我能够识别破坏构建的提交,通过迭代所有提交,执行mvn干净安装,并尝试启动服务器,直到我发现破坏它的delta.

不能为null的'contentItemRepository'是这样的:

@Component
+public class UrlAliasRequestConverter implements Mapper<UrlAliasRequest, UrlAlias> {
+
+    /**
+     * The content item contentItemType repository.
+     */
+    @Autowired
+    private ContentItemRepository contentItemRepository;

Answer 1

我在Ubuntu 16.04上遇到了同样的问题。

我发现问题出在

@ComponentScan(basePackages = "com.my.app")

该代码至少在5台不同的计算机上运行（Windows，Ubuntu 15.04和Ubuntu 16.04桌面），但没有启动CI服务器（Ubuntu 16.04服务器）。

我改变之后

@ComponentScan(basePackages = "com.my.app")

至

@ComponentScan(basePackages = {"com.my.app.service", "com.my.app.config", "com.my.app"})

该代码也在CI服务器上运行。

我认为这是bean loader的Spring问题...

更新：

https://github.com/spring-projects/spring-boot/issues/6045

https://jira.spring.io/browse/SPR-14307

Answer 2

这很可能与读取类文件的顺序有关

dir.listFiles() 在 PathMatchingResourcePatternResolver.doRetrieveMatchingFiles()

由于文件列表（类文件）的顺序取决于平台，并且没有对数组进行排序，因此加载类的顺序取决于平台如何返回它们。

参考（存档）：http : //forum.spring.io/forum/spring-projects/container/115998-circular-dependency-identification-inconsistent

Answer 3

我不明白为什么会发生这种情况，但这是我想出的唯一解决方案：

安装 Debian 8，它就可以工作了。

我在 Debian 7 的另一个全新安装中尝试了它，那里的错误较少，但仍然有一些。全新安装 Debian 8 似乎可以正常工作。

我只能得出结论，Java 必须调用某个系统库，这在某种程度上影响了 Spring 依赖项的解析顺序。该库必须在 Debian 8 中升级，使我与其他开发人员和生产正在使用的 Ubuntu 安装保持一致。

我不知道那个库可能是什么......扫描文件系统中的文件，以不同的顺序报告它们的东西？解压 .jar 文件并以不同顺序报告其内容的东西？

在我看来，我们的代码对依赖解析和注入的确切顺序如此敏感，这似乎是错误的，但事实似乎正是如此。它看起来也不像我们的代码中有任何东西应该使它对顺序敏感，我们没有做任何疯狂的事情，并且遵循相当标准的使用模式。

如果你问我的话，太多的春天魔法让纸牌屋屹立不倒。我的其他项目是在 DropWizard 上，并且依赖项注入是手动编码的，所以并不奇怪。

===更新

我将 Debian 7 盒子升级到 8，问题仍然存在。因此我关于它是库版本的假设是错误的。一定与我的环境有关。

我在盒子上创建了一个新用户。该用户的问题仍然存在。这个盒子有一些东西它确实不喜欢，但我不知道它是什么。

我想找到真正的原因并理解它，但我认为我无法真正投入更多的时间来弄清楚它。

不管怎样，全新安装 Debian 8 就可以解决这个问题。