为什么Spring在一台机器而不是另一台机器上出现循环依赖问题? [英] Why does Spring get circular dependency issues on one machine and not another?

问题描述

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

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.

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

I have seen this in the logs, suggesting that it is a circular reference problem that is leading to the instantiation failure:

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?

所以问题似乎在于，飞行路线需要一些依赖关系，而他们也需要飞行路线.

So the problem appears to be that flyway needs some dependencies and they need flyway.

问题是，为什么这只发生在我的环境中而不是其他人?即使在内存中使用H2的测试中，我也看到了问题，所以不是我的数据库出了问题.

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.

Spring自动装配是否有可能被某种方式混淆，并试图以错误的顺序执行操作，从而使存储库在尝试设置它时为空?

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?

对于排序依赖关系，Spring是否实现了不好的拓扑排序?

Does Spring have a badly implemented topological sort for ordering dependencies?

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

Why would it misbehave on my environment?

类路径的顺序会影响其行为吗?

Could ordering of the classpath influence its behaviour?

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

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

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

The application will not start with this error:

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签名为:

The ContentItemRepository signature is:

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

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

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

这曾经对我有用，并且通过遍历所有提交，执行mvn全新安装并尝试启动服务器，直到我发现破坏了它的增量，我能够确定破坏构建的提交

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.

不能为空的'contentItemRepository'是这个:

The 'contentItemRepository' that cannot be null is this one:

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

推荐答案

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

I don't understand why this happened, but here is the only solution that I came up with:

安装Debian 8，它可以工作.

Install Debian 8, and it works.

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

I tried it in another clean install of Debian 7, and got less errors there, but still had some. A clean install of Debian 8 seemed to work.

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

I can only conclude that Java must be calling some system library, that in some way affects the order in which Spring dependencies are resolved. That library must be upgraded in Debian 8, bringing me in-line with the Ubuntu installs that other devs and production are using.

我不知道该库可能是什么...扫描文件系统中文件的文件，以不同顺序报告它们吗?会解压缩.jar文件，以不同的顺序报告其内容吗?

I don't know what that library might be... Something that scans the files in the filesystem, reporting them in a different order? Something that unpacks a .jar file, reporting its contents in a different order?

在我看来，我们的代码对依赖关系解析和注入的确切顺序如此敏感，这似乎是错误的，但事实确实如此.看起来我们的代码中似乎没有什么应该使它对排序敏感，我们没有做任何疯狂的事情，并且遵循非常标准的用法模式.

It seems wrong to me that our code is so sensitive to the exact order of dependency resolution and injection, but that would appear to be the case. It also does not look like there is anything in our code that should make it sensitive to the ordering, we're not doing anything crazy, and following pretty standard patterns of usage.

如果您问我，太多的春季魔术使纸牌屋屹立不倒.我的其他项目都在DropWizard上，那里的依赖项注入是手动编码的，所以不会感到惊讶.

Too much Spring magic keeping the house of cards standing if you ask me. My other projects are on DropWizard, and there the dependency injection is manually coded up, so no surprises.

===更新

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

I upgraded the Debian 7 box to 8, and the problem still persists. Therefore my hypothesis about it being library version is wrong. Must be something about my environment.

我在包装盒上创建了一个新用户.该用户仍然存在问题.这个盒子确实有一些它不喜欢的东西，但是我无法弄清楚它是什么.

I created a new user on the box. The problem is still there for that user. There is something about this box it really does not like, but I cannot figure out what it is.

我想找到真正的原因并理解它，但是我认为我真的不能再花更多的时间来弄清它了.

I'd like to get to the real cause and understand it, but I don't think I can really dedicate any more time to figuring it out.

无论如何，全新安装的Debian 8可以解决问题.

Anyway, a clean install of Debian 8 solves the problem.

这篇关于为什么Spring在一台机器而不是另一台机器上出现循环依赖问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！