最近接手一套基于SpringBoot项目,对项目进行重构调整,将公共部分抽离成子项目。在实践的过程中,发现抽离之后的模板中组件并没有被初始化。于是将排查解决过程中搜集到的方案及知识汇总分享给大家。
问题原因
问题的原因很简单,因多套系统的package命名不一致。比如业务系统的包命名为com.abc.xx,而公共(common)部分的包命名为com.efg.xx,引入公共jar包时默认是无法初始化的。对于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注解。定义配置类,在配置类中指定要扫描的包路径:
@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 Configureorg.springframework.boot.autoconfigure.EnableAutoConfiguration=com.secbro.HelloWorldAutoConfiguration
该类是为SpringBoot提供的扫描入口。
此时,当其他项目需要该starter时,直接引入便可注入使用HelloWorldService类了。
关于此处建议大家专门看一篇相关的实战文章,可以更好的理解。这里只提供了一个大概的思路。
小结
关于SpringBoot的@ComponentScan基本上已经可以满足需求了,第二种方案是基于@ComponentScan的改进方案。而第三种方案更多的是基于SpringBoot的核心原理来处理的。当然最好是避免同一个项目使用多个顶级package。
通过本篇文章的脉络,我们可以看到一种学习的方式,通过一个知识点或一个实战中的问题,可以逐步将知识从点扩充到面,这样不仅能加大学习的范围,也能构建更牢固的知识图谱。