SpringJava配置的继承使用不同的bean

下面的示例显示了使用SpringJavaConfig显式连接依赖项，这导致在使用spring配置类的and接口时连接不同的bean

这似乎不应该发生，或者至少给出一个正常的警告，即有两个bean作为自动连接的候选，并且它不知道选择哪个

对这个问题有什么想法吗？我的猜测是，正如语法this.iConfig.a所暗示的那样，配置类之间没有实名间隔，如果只是因为没有警告2个候选bean，这会被认为是一个bug吗

public class Main
{
    public static void main( final String[] args )
    {
        final ApplicationContext context = new AnnotationConfigApplicationContext( IConfigImpl.class, ServiceConfig.class );
        final Test test = context.getBean( Test.class );

        System.out.println( test );
    }
}

public class Test
{
    private final String string;

    public Test( final String param )
    {
        this.string = param;
    }

    public String toString()
    {
        return this.string;
    }
}

@Configuration
public interface IConfig
{
    @Bean
    public String a();
}

@Configuration
public class IConfigImpl implements IConfig
{
    @Bean
    public String a()
    {
        return "GOOD String";
    }
}

@Configuration
public class ServiceConfig
{
    @Autowired
    IConfig iConfig;

    @Bean
    Test test()
    {
        return new Test( this.iConfig.a() );
    }

    @Bean
    String a()
    {
        return "BAD String";
    }
}

在本例中，我希望在测试对象中始终连接好的字符串，但在上下文加载器中翻转iconfigmpl.class、ServiceConfig.class的顺序会更改加载的字符串

使用弹簧4.0.7进行测试

---

编辑：进一步的测试表明这与内部配置无关。如果您删除IConfig界面，也会产生同样的结果。

我相信这是Spring多年来的行为

如果你重新定义了一个bean，那么作为最后一个加载的bean将获胜

另一个问题是，当使用java配置时，如何控制bean加载的顺序。查看这篇文章，它向您展示了如何使用另一个springjava配置的@Import进行排序

解决方案其实很简单——如果您需要覆盖以前的 定义的Bean没有说明使用 不同的bean名称，或者使用XML bean配置 被重写的bean和重写的bean或使用 @配置。XMLBean配置是本文的第一个示例 条目中，带有@Configuration的条目如下所示：

他提到了秩序问题。下面是关于他们的答案

---

重写相同名称的bean是有意义的，但在本例中，我 具体引用iConfig中指定的bean 配置我希望得到那里指定的那个

为了实现@Configuration和bean的缓存，以便

@Configuration
class Example {
    @Bean
    public UncaughtExceptionHandler uncaughtExceptionHandler() {
        return (thread, throwable) -> System.out.println(thread + " => " + throwable.getMessage());
    }

    @Bean
    @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    public Thread newThread() {
        Thread thread = new Thread();
        thread.setUncaughtExceptionHandler(uncaughtExceptionHandler()); // <<<<<< allowing this
        return thread;
    }
}

不是真的在调用iconfigmpla。从4.2开始，它从代理拦截器调用。代码使用相应的方法确定目标bean名称，并使用ApplicationContext的BeanFactory解析该bean。由于名为a的bean的bean定义已被重写，因此将使用新的bean定义。该bean定义使用ServiceConfiga方法作为其工厂方法

文档中对此进行了描述

所有@Configuration类都在启动时使用CGLIB进行子类化。 在子类中，子方法首先检查容器是否存在任何错误 在调用父方法并创建 新实例

这会被认为是一个bug[…]吗

---

我不这么认为。这种行为被记录在案

重写相同名称的bean是有意义的，但在本例中，我特别引用了iConfig配置中指定的bean。我希望得到一个指定的那里。谢谢，内部实施细节清楚了。我不能百分之百确定这个.iConfig.a不会给我那个豆子，但我知道为什么会这样，这看起来还是很遗憾。

@Configuration
class Example {
    @Bean
    public UncaughtExceptionHandler uncaughtExceptionHandler() {
        return (thread, throwable) -> System.out.println(thread + " => " + throwable.getMessage());
    }

    @Bean
    @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    public Thread newThread() {
        Thread thread = new Thread();
        thread.setUncaughtExceptionHandler(uncaughtExceptionHandler()); // <<<<<< allowing this
        return thread;
    }
}

return new Test(this.iConfig.a());