标记 @ConditionalOnBean 的实例通过 getBeansOfType 时没有成功初始化

[JonasGao]

现有场景如下

class Configuration1 implements ApplicationContextAware {
  @Bean
  @ConditionalOnBean(Interface1.class)
  Service1 service1(Interface1 interface1) {
    return new Service1(interface1);
  }

  @Bean
  Service2 service2() {
    Service1 service1 = applicationContext.getBeansOfType(Service1.class);
    return new Service2(service1);
  }
  
  // TODO about save applicationContext
}

@Configuration
@Import(Configuration1.class)
class AutoConfiguration1 {
}

@Import(Interface1Impl1.class)
@interface EnableInterface1Impl1 {
}

@SpringBootApplication
@ComponentScan("<current pkg>")
@EnableInterface1Impl1
class A {
  public static void main(String[] args) {
    SpringApplication.run(A.class, args);
  }
}

最终启动时，service2 的示例找不到 service1 的示例。也就是这种情况下，@ConditionalOnBean 的判断为 false。最终启动失败

[JonasGao]

0. 首先需要明确，类似 @Import 和 @Enable* 这类注解的处理顺序是跟随其所位于的配置类来的
1. 那么，在 Spring 启动的配置加载顺序中，A 作为启动类。其在处理顺序的位置中是低于被明确标记为 @Configuration 的 AutoConfiguration1 的。所以 @EnableInterface1Impl1 的处理位置要低于 @ConditionalOnBean(Interface1.class)
2. 尝试为 AutoConfiguration1 注册到 spring.factories 中后。仍然报错。
3. 理论上注册到 spring.factories 中的配置类，其顺序是必然低于启动类的。启动失败，是因为顺序没有因此而真的改变
4. 核心原因是因为 @ComponentScan 的存在。如果删除该注解。则可以启动成功

以上可以参考 Spring 的 ConfigurationClassPostProcessor 和 ConfigurationClassParser

[JonasGao]

将扫描配置写到 @SpringBootApplication 则可以成功。说明 @ComponentScan 的扫描处理和 @SpringBootApplication(scanBasePackages="xxx") 是有不同的

[JonasGao]

spring.factories 的具体特殊处理是什么。为什么标记后，配置顺序一般都靠后