作者 | 敖丙
来源 | 敖丙
今天同事火急火燎的走了过来,说:快帮我看看这个错误,啥情况啊?
我一看报错:
Field xxxService in com.xx.xx.service.impl.XxXServiceImpl required a bean of type 'com.xx.xx.service.XxxService' that could not be found.
我其实已经知道是啥情况了,但是怕他不知道,所以还是耐心的跟她解释了一下,她听完后说:能不能写下来啊,免得我下次还会忘。
这个错误其实就是这个Bean在Spring容器中找不到,发生这种错误时,常见的有两种情况:
1、@ComponentScan注解里的扫描路径没包含这个类
2、这个类的头上没加@Component注解
那么问题就来了:为什么@ComponentScan没扫描到或者没加@Component注解就注入不到Spring容器中?这个问题有点无厘头(没加@Component注解你还想注入到Spring容器中?)
我换种问法:为什么@ComponentScan扫描到了并且加了@Component注解就能注入到Spring容器中?
当然你可以直接回答:因为Spring规定这样做的
当然我也会接着反问你:Mybatis的Mapper就没用@Component注解,凭啥它就能注入到Spring容器中?
问题分析
要回答:为什么@ComponentScan扫描到了并且加了@Component注解就能注入到Spring容器中?
我们首先需要对问题进行拆解:
1、@ComponentScan扫描是做了什么?
2、加了@Component注解又代表了什么?
回答了这两个问题我们再进行猜想:以上过程是否可以进行自定义?如何自定义?否则就没有办法说明Mapper是如何注入到Spring容器中的。
@ComponentScan扫描是做了什么?
这个过程大概是这样的:Spring通过扫描指定包下的类,解析这些类的信息,转化成为BeanDefinition,注册到beanDefinitionMap中。
那么这个过程的详情情况又是如何呢?
我们先来了解一下这个过程中涉及到的角色:
1、BeanDefinition:Bean定义,内含Class的相关信息
2、ConfigurationClassPostProcessor:配置类处理器,查找配置类,创建配置类解析器
3、ConfigurationClassParser:配置类解析器,解析配置类,创建@ComponentScan注解解析器
4、ComponentScanAnnotationParser:@ComponentScan注解解析器,解析@ComponentScan注解,创建Bean定义扫描器
5、ClassPathBeanDefinitionScanner:Bean定义扫描器,扫描指定包下的所有类,将符合的类转化为BeanDefinition
6、BeanDefinitionRegistry:BeanDefinition注册器,注册BeanDefinition
从上往下看,我们可以轻易的发现,这整个过程有一种层层递进的关系:
下面我们再来看看这些角色的具体职责。
1.配置类处理器
配置类处理器主要做了3件事
1、查找配置类
2、创建配置类解析器并调用
3、加载配置类解析器所返回的@Import与@Bean注解的类
1.1查找配置类
你可能会有疑惑,配置类不是我们传入的吗?为什么还需要去查找配置类呢?
这是因为Spring整个调用链路十分复杂,不可能说把配置类往下层层传递,而是一开始时就将配置类注册到BeanDefinitonMap中了。
查找配置类大致有两个过程:
1、从BeanFactory中获取到所有的BeanDefiniton信息
2、判断BeanDefiniton是否为配置类
第一步很好解决,所有的BeanDefiniton是放在BeanFactory的BeanDefinitonMap中,直接从中获取就可以了。
而对于第二点,首先我们要知道什么是配置类?
在Spring中,有两种配置类:
1、full类型:标识了@Configuration注解的类
2、lite类型:
标识了@Component @ComponentScan @Import @ImportResource @Bean 注解的类(其中之一就行)
他们唯一的区别就在于:full类型的类会在后置处理步骤中进行动态代理
@Configuraiton
public class MyConfiguration{@Beanpublic Car car(){return new Car(wheel());}@Beanpublic Wheel wheel(){return new Wheel();}
}
当查找出所有的配置类信息之后,紧接着就是创建配置类解析器,并将所有的配置类交由配置类解析器进行解析
1.2流程图
2.配置类解析器
配置类解析器的职责如下:
判断该类是否应该跳过解析
解析内部类信息
解析@PropertySources注解信息
解析@ComponentScan注解信息
解析@Import注解信息
解析@Bean注解信息
2.1判断该类是否应该跳过解析
所谓判断类是否应该跳过解析,其实就是判断类是否标识了@Conditional注解并且是否满足该条件。如果标识了该注解并且不满足条件,那么则跳过解析步骤。
如我们常见的@Profile,@ConditionalOnMissBean等都是由此控制。
2.2解析内部类信息
有时候我们的配置类里面有内部类,并且内部类也是个配置类,那么就需要用此方式进行解析。
2.3解析@ComponentScan注解信息
该步骤主要是利用**@ComponentScan注解解析器进行解析@ComponentScan注解,从而获取到BeanDefinition列表,再判断这些BeanDefinition是否是个配置类,是则再次调用配置类解析器**进行递归解析。
3.@ComponentScan注解解析器
在该步骤中,Spring会将我们配置在@ComponentScan注解上的所有信息提取出来,存入到Bean定义扫描器中,再利用Bean定义扫描器得到符合条件的BeanDefiniton。
excludeFilter和includeFilter用于扫描时判断class是否符合要求。
默认的excludeFilter:扫描时排除掉自己这个class
默认的includeFilter: 扫描时判断该class是否标识@Component注解
4.Bean定义扫描器
BeanDefinitionScanner主要做了三件事:
1、扫描包路径下的类
2、给BeanDefiniton设值
3、使用BeanDefinition注册器将BeanDefiniton注册到容器中
4.1扫描包路径下的类
扫描包路径的步骤可以简单理解为遍历class文件的过程,遍历包下的每个class,判断该class是否满足条件——标识了@Component注解,将满足条件的class转化为BeanDefiniton,此时BeanDefiniton只有metedata信息,还没有具体设值。
4.2给BeanDefiniton设值
如果我们在类上加了类似这些注解:@Lazy @Primary @DependsOn,那么就需要将这些注解转化为实际的属性设到BeanDefiniton中。
4.3流程图
5.BeanDefinition注册器
BeanDefinitionRegistry的作用就是将BeanDefiniton放到BeanDefinitonMap中
思考
现在我们已经知道了扫描包的整体过程,再来回顾一下这个问题:Mybatis的Mapper是怎么注入到Spring容器中的?
像这种问题咋一看很难理解,常常在面试的情况发生,因为面试官是拿着答案问问题。
但是我们思考的话,就应该换个角度:怎么才能让Mapper注册到Spring中 -> 怎么才能让自定义的注解标识的Class注册到Spring中?
不知道这样问是否简单些呢?
方法
1.使用TypeFilter
我们知道@Component注解是和默认注册的IncludeFilter配套使用的,那么同样我们也可以使用一个自定义的IncludeFilter与我们的自定义注解配套使用
自定义Mapper注解
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Mapper {
}
使用Mapper
@Mapper
public class MyMapper {public void hello(){System.out.println("myMapper hello");}
}
测试
添加一个自定义的IncludeFilter进行测试
**注意:**此方式只能支持自定义注解标识在实体类的情况,如果将Mapper注解加在接口上,则你会收获一个异常:No bean named 'myMapper' available
答案很简单,因为接口不能实例化,所以Spring默认判断如果该类非实体类,则不注册到容器中。
那么我们怎么才能让加了Mapper注解的接口能注册到Spring中呢?
2.自定义扫描器
既然Spring的扫描器无法支持接口,那么我们就重写它——的判断逻辑。
所以我们方式很简单:继承ClassPathBeanDefinitionScanner,重写判断Class是否符合的逻辑
public class ClassPathMapperScanner extends ClassPathBeanDefinitionScanner {@Overrideprotected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {// 重写判断beanDefinition是否为接口逻辑,改为只有类为接口时才允许注册return beanDefinition.getMetadata().isInterface() && beanDefinition.getMetadata().isIndependent();}//省略构造方法
}
逻辑已经改好了,现在迎来一个新问题:怎么让Spring使用它?
通过整体流程我们知道,Bean定义扫描器是在**@ComponentScan注解解析器**的解析流程中创建(new)出来的,我们又不能更改这个流程,所以, Game Over?
但,为什么一定要在Spring的扫描流程中使用我们的扫描器呢?我们可以在Spring的扫描流程结束后,再扫描一遍不就好了吗?
还记得有什么方式可以做到这件事吗?后置处理器!
3.使用后置处理器
我们通过使用BeanDefinitionRegistryPostProcessor,让Spring的扫描流程结束之后,进行一次后置处理。在后置处理中,创建出自定义的扫描器,进行第二次扫描。
@Component
public class MapperScannerProcessor implements BeanDefinitionRegistryPostProcessor {@Overridepublic void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {// 创建出自定义的扫描器ClassPathMapperScanner classPathMapperScanner = new ClassPathMapperScanner(registry, false);// 添加filter,class添加了Mapper注解才注册到Spring中classPathMapperScanner.addIncludeFilter(new AnnotationTypeFilter(Mapper.class));// 这里可以改为从外部设值,不必写死classPathMapperScanner.scan("com.my.spring.test.custom");}
}
使用这种方式,你会发现,我们的接口确实注册到BeanDefinitionMap中了。
但是,你仍然会收到一个错误:
Failed to instantiate [com.my.spring.test.custom.InterfaceMapper]: Specified class is an interface
接口确实是无法实例化的,虽然我们把它注册到了Spring中。但Mybatis又是怎么做的呢?
答案是替换,Mybatis将图中的beanClass替换成了FactoryBean: MapperFactoryBean,然后将原有的beanClass放入了它的mapperInterface属性中
它的getObject方法长这样
public T getObject() throws Exception {return getSqlSession().getMapper(this.mapperInterface);
}
好了,关于思考的内容就到这里,我们只是借用Mybatis的现象进行思考,再深入就是Mybatis的内容了。
小结
本文借助一个开发时常见的问题进行分析,介绍了Spring的配置类解析与扫描过程,同时,还借助了Mybatis中的现象,思考怎么才能让自定义的注解标识Class注册到Spring中这一问题,并使用案例给出了一份较好的答案,希望大家能够通过案例更加深入的了解该流程。
同样,通过本次学习,来评论区回答以下问题吧~
1、什么是配置类?Spring中有哪几种配置类?有什么区别?
2、BeanDefinitionRegistryPostProcessor有什么用?你知道哪些案例吗?
往期推荐
Android 13 第一个开发者版本来了,网友直呼:Android 12 还没玩透!
好饭不怕晚,扒一下 Redis 的配置文件
使用这个库,让你的服务操作 Redis 速度飞起
使用 Cilium 增强 Kubernetes 网络安全
点分享
点收藏
点点赞
点在看