最近接手一套基于SpringBoot项目,对项目进行重构调整,将公共部分抽离成子项目。在实践的过程中,发现抽离之后的模板中组件并没有被初始化。于是将排查解决过程中搜集到的方案及知识汇总分享给大家。

问题原因

问题的原因很简单,因多套系统的package命名不一致。比如业务系统的包命名为com.abc.xx,而公共(common)部分的包命名为com.efg.xx,引入公共jar包时默认是无法初始化的。

springboot

对于SpringBoot项目,我们知道扫描的路径从启动类所在包开始,扫描当前包及其子级包下的所有文件。上图如果启动类在com.abc包下,肯定是无法扫描到com.def包内的组件的。

场景延伸

SpringBoot的这个机制还延伸出另外两个场景。

第一个场景是如果SpringBoot的启动类放的包路径靠下,那么在它上级目录中的组件是无法被扫描并初始化的。新手往往会因放错位置导致启动时异常。

第二个场景是故意将一些不需要纳入SpringBoot容器的类放在其他包中,避免被SpringBoot容器加载。当然此时也可以使用ComponentScan来指定排除对应的包。

├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── secbro
│   │   │           ├── SpringBootMainApplication.java
│   │   │           ├── controller
│   │   │           │   └── DruidController.java
│   │   │           ├── model
│   │   │           │   └── Order.java
│   │   │           └── service
│   │   │               ├── OrderService.java
│   │   │               └── impl
│   │   │                   └── OrderServiceImpl.java

上述项目结构中,如果将类直接放在com目录或com目录的其他子目录下,默认是不会被初始化的。

通过@ComponentScan扫描

回到正题,遇到类似不被初始化的情况,我们可以使用的最简单的方案就是手动指定扫描包路径。

在启动类上的@SpringBootApplication注解内部集成了@ComponentScan注解。此时我们可以显示的指定扫描的包。

@SpringBootApplication
@ComponentScan({"com.abc.xx","com.def.xx"})
public class SpringBootMainApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringBootMainApplication.class, args);
    }

}

此种用法一定要先包含本项目要扫描的路径“com.abc.xx”,然后再在后面添加上common项目要扫描的路径“com.def.xx”。

如果其他项目不需要初始化common中的内容,则可不进行指定。

自定义@Enable****注解

上述方法虽然能够解决问题,但如果直接写包名,难免没有个统一的规范。此时可考虑使用@Enable类型的注解。

了解SpringBoot机制的朋友都知道,最重要的一个注解便是@EnableAutoConfiguration。类似的,我们定义一个可以通过注解之后便可使用的Enable注解。

springboot

定义配置类,在配置类中指定要扫描的包路径:

@Component
@ComponentScan("com.def.xx")
public class CommonConfig {
}

定义Enable注解类,并通过@Import导入配置类:

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(CommonConfig.class)
public @interface EnableCommon {
}

然后,在启动类中便可使用@EnableCommon此注解来指定实例化对应的package。

@EnableCommon
@SpringBootApplication
public class SpringBootMainApplication {
// ...
}

在此过程中需要注意的是CommonConfig是位于common项目当中的。如果CommonConfig直接可被SpringBoot扫描到,那也就不需要EnableCommon注解了。

自定义starter

我们使用SpringBoot之所以方便,得益于它的特性之一便是可以使用已经集成好的starter。同样,我们也可以自定义一套starter来达到自动化配置的效果。

由于这种模式更适用于自动化集成某一个组件,并不太适合这里说的common公共项目。因此就不再代码演示,只说一下大概的思路。详细实例可参考我的新书《SpringBoot技术内幕:架构设计与实现原理》。

定义starter首先需要依赖自动配置的组件,也就是pom文件中添加如下配置:

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-autoconfigure</artifactId>
  </dependency>
</dependencies>

然后再定义具体的服务(或初始化)类,比如HelloWorldService以及该服务类初始化的参数类HelloWorldProperties。通过@ConfigurationProperties注解可以将Application中对应的属性初始化到类的属性中。

然后呢,再提供一个基于@ConditionalOnClass配置的HelloWorldAutoConfiguration类,指定当HelloWorldService存在于类路径时,便会进行初始化。

最后一步,在META-INF目录下创建spring.factories,启动添加类似如下配置:

# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.secbro.HelloWorldAutoConfiguration

该类是为SpringBoot提供的扫描入口。

此时,当其他项目需要该starter时,直接引入便可注入使用HelloWorldService类了。

关于此处建议大家专门看一篇相关的实战文章,可以更好的理解。这里只提供了一个大概的思路。

小结

关于SpringBoot的@ComponentScan基本上已经可以满足需求了,第二种方案是基于@ComponentScan的改进方案。而第三种方案更多的是基于SpringBoot的核心原理来处理的。当然最好是避免同一个项目使用多个顶级package。

通过本篇文章的脉络,我们可以看到一种学习的方式,通过一个知识点或一个实战中的问题,可以逐步将知识从点扩充到面,这样不仅能加大学习的范围,也能构建更牢固的知识图谱。



SpringBoot扫描不到组件?给你提供几种方案插图(2)

关注公众号:程序新视界,一个让你软实力、硬技术同步提升的平台

除非注明,否则均为程序新视界原创文章,转载必须以链接形式标明本文链接

本文链接:https://www.choupangxia.com/2020/10/17/springboot/