Spring源码解读 - IOC xml配置解析（二）- 自定义标签解析与component-scan原理（一）
这个问题其实上一篇有讲过，这边再复述一遍，在 spring
的 xml
配置文件中，我们可以把所有的标签分为两类：自定义标签和默认标签，区别如下
<!-- 标签前面有 xxx:即是spring的自定义标签，我们也可以自己定义一个xiaozize:的标签-之后会讲到 -->
<context:component-scan base-package="com.xiaoxizi.spring"/>
<!-- 该标签对应的命名空间在xml文件头部beans标签中声明 -->
<beans xmlns:context="http://www.springframework.org/schema/context" ... />
<!-- 默认标签没有 xx: 前缀 -->
<bean class="com.xiaoxizi.spring.service.AccountServiceImpl"
id="accountService" scope="singleton" primary="true"/>
<!-- 对应的命名空间也在xml文件头部beans标签中声明 -->
<beans xmlns="http://www.springframework.org/schema/beans" ... />
复制代码
需要注意的是，自定义标签的概念，并不完全只指我们开发时自己定义的标签，而是spring的开发者为之后拓展预留的 拓展点 ，这个拓展点我们可以用，spring的开发人员在为spring添加新功能时，也可以使用。
2. 关于 spring
内置的自定义标签 context:component-scan
我们现在的开发中，更多的情况下，其实是使用 @Configuration
、 @Component
、 @Service
等注解来进行 bean
的声明而不是使用 xml
的 bean
标签了。
那么为什么一个类加上了这些注解之后，就能被spring管理了呢？
实际上这些 拓展功能
是 spring
通过自己预留的自定义标签的拓展点进行拓展的，对于上述的功能，具体是使用的 context:component-scan
标签。
我们今天就通过对自定义标签 context:component-scan
的解析来跟踪一下相应的源码，理解 spring
自定义标签解析的流程，同时也对 context:component-scan
实现的功能做一个讲解，看一下 @Component
等标签的实现原理。
二、源码解析
1. 自定义标签解析过程
由于上一篇对xml的源码跟过了，这期我们之间定位到相应代码 org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader#parseBeanDefinitions
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
// 判断是否是默认的命名空间
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
if (delegate.isDefaultNamespace(ele)) {
// 解析默认标签
parseDefaultElement(ele, delegate);
}
else {
// 可以看到代理主要进行自定义标签的解析
delegate.parseCustomElement(ele);
}
}
}
}
else {
// 可以看到代理主要进行自定义标签的解析
delegate.parseCustomElement(root);
}
}
@Nullable
public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
// 获取标签对于的namespaceUrl, 即配置文件头部beans标签里面那些xmlns:xxx=www.xxx.com
String namespaceUri = getNamespaceURI(ele);
if (namespaceUri == null) {
return null;
}
// 获取自定义标签对应的NamespaceHandler，从这里我们可以看到，对于每一个namespaceUri应该都有唯一一个对应的NamespaceHandler
NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
if (handler == null) {
error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
return null;
}
// 把自定义标签委托给对应的NamespaceHandler解析
return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
}
复制代码
我们先看一下 NamespaceHandler
这个自定义标签的解析接口的结构：
public interface NamespaceHandler {
// 初始化，我们可以合理猜测，这个方法将会在NamespaceHandler实例化之后，使用之前调用
void init();
// xml解析入口
@Nullable
BeanDefinition parse(Element element, ParserContext parserContext);
// 装饰接口，其实用的比较少，上一篇有稍微带到过一下，默认bean标签解析完之后，可以有一个机会对解析出来的beanDefinition进行装饰，实际开发中很少使用
// 有兴趣的同学可以自行看下源码，源码在 org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader#processBeanDefinition
@Nullable
BeanDefinitionHolder decorate(Node source, BeanDefinitionHolder definition, ParserContext parserContext);
}
复制代码
接下来当然是需要看一下获取 NamespaceHandler
的流程：
public NamespaceHandler resolve(String namespaceUri) {
// 获取到了一个handlerMapping，具体逻辑我们之后再看
Map<String, Object> handlerMappings = getHandlerMappings();
// 通过namespaceUri获取到一个对象
Object handlerOrClassName = handlerMappings.get(namespaceUri);
if (handlerOrClassName == null) {
return null;
}
// 如果handlerOrClassName是一个NamespaceHandler对象，则直接返回 - 拿到对应的handler了
else if (handlerOrClassName instanceof NamespaceHandler) {
return (NamespaceHandler) handlerOrClassName;
}
else {
// 如果handlerOrClassName不是NamespaceHandler对象，则是String对象
String className = (String) handlerOrClassName;
// 通过String获取到一个Class对象，那么这个String对象肯定是一个类的全限定名啦
Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);
// handlerClass必须继承自NamespaceHandler，很好理解，毕竟是spring提供的拓展点，自然需要符合它定义的规则
if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) {
throw new FatalBeanException("...");
}
// 直接通过反射构造一个实例，点进去看会发现是调用的无参构造器，我们就不看了
NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);
// !!! 调用了init()方法，和我们之前的推测一致
namespaceHandler.init();
// !!! 把handler对象塞回了handlerMappings，所以我们下次再通过namespaceUri获取时，会直接拿到一个NamespaceHandler对象
// 也即每个namespaceUri对应的NamespaceHandler对象是单例的，而init()方法也只会调用一次
handlerMappings.put(namespaceUri, namespaceHandler);
return namespaceHandler;
// 去除掉了异常处理
}
}
复制代码
由上述源码其实我们已经得知了 NamespaceHandler
的一个初始化过程，但其实还有一个疑问，就是这个 handlerMappings
中最初的那些 namespaceUri
对应的handler的类名是哪来的呢？这个时候我们就需要去看一下 getHandlerMappings()
的过程啦
private Map<String, Object> getHandlerMappings() {
Map<String, Object> handlerMappings = this.handlerMappings;
if (handlerMappings == null) {
synchronized (this) {
handlerMappings = this.handlerMappings;
// 双重检查加锁，看来我们的handlerMappings之后加载一次
if (handlerMappings == null) {
// 可以看到这边是去加载了文件
// 文件加载的过程我们就不去跟了，跟主流程关系不大，我们主要看一下这个文件位置
// this.handlerMappingsLocation是哪里
Properties mappings =
PropertiesLoaderUtils.loadAllProperties(this.handlerMappingsLocation, this.classLoader);
handlerMappings = new ConcurrentHashMap<>(mappings.size());
// 然后把文件中的kev-value属性都合并到了一个map里
CollectionUtils.mergePropertiesIntoMap(mappings, handlerMappings);
this.handlerMappings = handlerMappings;
// 干掉了异常处理代码
}
}
}
return handlerMappings;
}
// 字段的定义， 需要说一下当前类是DefaultNamespaceHandlerResolver，喜欢自己探索的同学可以直接空降
/** Resource location to search for. */
private final String handlerMappingsLocation;
// 可以看到这个值是Resolver的构造器中设值的
public DefaultNamespaceHandlerResolver(@Nullable ClassLoader classLoader, String handlerMappingsLocation) {
this.classLoader = (classLoader != null ? classLoader : ClassUtils.getDefaultClassLoader());
this.handlerMappingsLocation = handlerMappingsLocation;
}
// 默认是取的DEFAULT_HANDLER_MAPPINGS_LOCATION这个常量
public DefaultNamespaceHandlerResolver() {
this(null, DEFAULT_HANDLER_MAPPINGS_LOCATION);
}
// 我们看一下这个常量的值
public static final String DEFAULT_HANDLER_MAPPINGS_LOCATION = "META-INF/spring.handlers";
复制代码
如果对 SPI
比较熟悉的同学，应该已经知道这是个什么套路了，并且对 META-INF
这个目录也比较熟悉，那么现在，我们看一下这个 META-INF/spring.handlers
文件中到底写了一些什么东西，以 context:component-scan
标签为例，我们知道这个标签是spring-context包里面提供的，直接去找这个jar包的对应文件，看一下里面的内容：
## 我们可以很明显的看到一个key=value结构 http/://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler http/://www.springframework.org/schema/jee=org.springframework.ejb.config.JeeNamespaceHandler http/://www.springframework.org/schema/lang=org.springframework.scripting.config.LangNamespaceHandler http/://www.springframework.org/schema/task=org.springframework.scheduling.config.TaskNamespaceHandler http/://www.springframework.org/schema/cache=org.springframework.cache.config.CacheNamespaceHandler 复制代码
我们在回忆一下自定义标签的定义：
<!-- 标签前面有 xxx:即是spring的自定义标签，我们也可以自己定义一个xiaozize:的标签-之后会讲到 --> <context:component-scan base-package="com.xiaoxizi.spring"/> <!-- 该标签对应的命名空间在xml文件头部beans标签中声明 --> <beans xmlns:context="http://www.springframework.org/schema/context" ... /> 复制代码
可以看到我们的 META-INF/spring.handlers
文件中 key
就是自定义标签的 namespaceUri
， value
则是对应的 NamespaceHandler
的全限定名。
那么简单总结一下，我们的自定义标签解析的流程就是：
-
加载所有jar中
META-INF/spring.handlers文件中的namespaceUri和NamespaceHandler的全限定名的映射关系到handlerMappings -
根据
namespaceUri从handlerMappings获取对象-
如果从
handlerMappings获取到的对象为空，直接返回 -
如果获取到的是
NamespaceHandler对象，直接使用 -
如果获取到的对象是string类型，则实例化这个string对应的全限定名的
NamespaceHandler对象，并调用init()方法，然后将namespaceUri-NamespaceHandler对象关系放回handlerMappings
-
-
将自定义标签委托给2获取到的
NamespaceHandler对象解析-调用parse方法（如果2未获取到对应的NamespaceHandler对象，则此自定义标签无法解析，直接跳过）
2. context:component-scan
标签工作原理
接下来我们来看一下 context:component-scan
标签的工作原理，从spring-context包的 META-INF/spring.handlers
文件我们可以找到该标签对应的处理器：
http/://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler 复制代码
直接找到这个类：
public class ContextNamespaceHandler extends NamespaceHandlerSupport {
@Override
public void init() {
// 删掉了一些我们不关注的标签的Parser的注入代码...
// 我们可以看到这里注册了一个BeanDefinitionParser，而且这个注册方法的第一个参数明显是
// `context:component-scan` 标签中删掉前缀的部分，我们先记下来
registerBeanDefinitionParser("component-scan", new ComponentScanBeanDefinitionParser());
// 删掉了一些我们不关注的标签的Parser的注入代码...
}
}
复制代码
可以看到 ContextNamespaceHandler
继承自 NamespaceHandlerSupport
，这是一个典型的模本方法设计模式。这里不做拓展，我们直接看一下 NamespaceHandlerSupport
：
// 这里我们只保存了与解析器相关的代码，并且调整了一下源码顺序
// 装饰相关的代码我去除掉了，并不是NamespaceHandlerSupport中没有，不过它的逻辑和解析基本是一致的
// 如果同学们还记得哪里对beanDefinition进行了装饰，并且感兴趣的话，可以自行了解一下 (*￣︶￣)
public abstract class NamespaceHandlerSupport implements NamespaceHandler {
// 保存标签名-解析器对应关系的容器
private final Map<String, BeanDefinitionParser> parsers = new HashMap<>();
// 保存标签名-装饰器对应关系的容器
private final Map<String, BeanDefinitionDecorator> decorators = new HashMap<>();
// 保存属性名-装饰器对应关系的容器
private final Map<String, BeanDefinitionDecorator> attributeDecorators = new HashMap<>();
// 可以看到我们init()方法中的register其实就只是把对应elementName-Parser放入map而已
protected final void registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser) {
this.parsers.put(elementName, parser);
}
public BeanDefinition parse(Element element, ParserContext parserContext) {
// 获取 Parser
BeanDefinitionParser parser = findParserForElement(element, parserContext);
// 委托给 Parser解析
return (parser != null ? parser.parse(element, parserContext) : null);
}
private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) {
// 这里是获取了去掉标签中去掉前缀后的名称 context:component-scan --> component-scan
String localName = parserContext.getDelegate().getLocalName(element);
// 从map中获取到对应的Parser
return this.parsers.get(localName);
}
}
复制代码
到此为止其实还是蛮简单的嘛，我们又把标签委托给了对应的 Parser
来处理，那么我们现在来看一下 component-scan
对应的 ComponentScanBeanDefinitionParser
的逻辑，我们先看parse方法，也是我们的入口方法：
public BeanDefinition parse(Element element, ParserContext parserContext) {
// 获取标签上配置并处理的base-package属性
String basePackage = element.getAttribute(BASE_PACKAGE_ATTRIBUTE);
// 处理占位符
basePackage = parserContext.getReaderContext().getEnvironment().resolvePlaceholders(basePackage);
// 最终获取到的是一个数组 - 因为我们配置的时候是可以配置多个的
String[] basePackages = StringUtils.tokenizeToStringArray(basePackage,
ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
// 获取一个扫描器 - 这个东西很重要，我们以后还会看到
ClassPathBeanDefinitionScanner scanner = configureScanner(parserContext, element);
// 嗯，扫描器进行扫描，看来就是这个方法会扫描那些注解了
Set<BeanDefinitionHolder> beanDefinitions = scanner.doScan(basePackages);
// 注册一些组件
registerComponents(parserContext.getReaderContext(), beanDefinitions, element);
return null;
}
复制代码
我们先看一下扫描器是怎么创建出来的：
// 把一些异常处理都干掉了
protected ClassPathBeanDefinitionScanner configureScanner(ParserContext parserContext, Element element) {
// 解析一下是否用默认的过滤器 --> 这里解释一下，其实这个过滤器就是指我们那些注解@Service等。
// 其实这里就是定义那些注解是我们扫描到了之后会把它纳入IOC管理的，具体代码之后解析的时候会看到
boolean useDefaultFilters = true;
if (element.hasAttribute(USE_DEFAULT_FILTERS_ATTRIBUTE)) {
useDefaultFilters = Boolean.parseBoolean(element.getAttribute(USE_DEFAULT_FILTERS_ATTRIBUTE));
}
// 直接创建一个扫描器
ClassPathBeanDefinitionScanner scanner = createScanner(parserContext.getReaderContext(), useDefaultFilters);
// 从parserContext获取到的默认的beanDefinition的配置，即之后解析的beanDefinition的缺省配置
scanner.setBeanDefinitionDefaults(parserContext.getDelegate().getBeanDefinitionDefaults());
// 从parserContext获取到的默认的自动装配的模式，byType、byName那些
scanner.setAutowireCandidatePatterns(parserContext.getDelegate().getAutowireCandidatePatterns());
// 扫描的资源路径，一般我们也不配置
if (element.hasAttribute(RESOURCE_PATTERN_ATTRIBUTE)) {
scanner.setResourcePattern(element.getAttribute(RESOURCE_PATTERN_ATTRIBUTE));
}
// 没什么用的...一般也不会去自定义，即使用注解时，生成bean的name的策略也可以自定义
parseBeanNameGenerator(element, scanner);
// 基本也不用，scope相关的，大概意思就是这个bean会存在于哪些scope，一般不用
parseScope(element, scanner);
// 解析类型过滤器-这个算相对重要，其实就是我们可以自定义需要扫描哪些注解
parseTypeFilters(element, scanner, parserContext);
return scanner;
}
复制代码
我们先看一下如果 useDefaultFilters=true
会注册哪些过滤器， createScanner
中其实就是直接调用了构造器，那我们直接看一下构造器逻辑：
public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry,
boolean useDefaultFilters,
Environment environment,
@Nullable ResourceLoader resourceLoader) {
Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
this.registry = registry;
if (useDefaultFilters) {
// 注册默认的过滤器
registerDefaultFilters();
}
setEnvironment(environment);
setResourceLoader(resourceLoader);
}
protected void registerDefaultFilters() {
// includeFilters添加了一个AnnotationTypeFilter，过滤器构造器传入了Component的Class对象
this.includeFilters.add(new AnnotationTypeFilter(Component.class));
// 省略了两个JSR规范注解的注册代码，我们一般用不到，@javax.annotation.ManagedBean和@javax.inject.Named
}
复制代码
由于 Filter
的匹配过程不是主流程，不在这里多写，但是我会写一段源码解析到这一节的末尾，感兴趣的同学也可以看一下。
我们解析来看一下类型过滤器标签的解析：
protected void parseTypeFilters(Element element, ClassPathBeanDefinitionScanner scanner, ParserContext parserContext) {
// ...
NodeList nodeList = element.getChildNodes();
for (int i = 0; i < nodeList.getLength(); i++) {
Node node = nodeList.item(i);
// 找到每一个子节点
if (node.getNodeType() == Node.ELEMENT_NODE) {
String localName = parserContext.getDelegate().getLocalName(node);
if (INCLUDE_FILTER_ELEMENT.equals(localName)) {
// 如果是<include-filter/>标签则创建一个Filter并加入includeFilters
TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext);
scanner.addIncludeFilter(typeFilter);
}
else if (EXCLUDE_FILTER_ELEMENT.equals(localName)) {
// 如果是<exclude-filter/>标签则创建一个Filter并加入includeFilters
TypeFilter typeFilter = createTypeFilter((Element) node, classLoader, parserContext);
scanner.addExcludeFilter(typeFilter);
}
}
}
}
复制代码
那么我们看一下 createTypeFilter
究竟做了一些什么：
// 逻辑还是比较直观的
protected TypeFilter createTypeFilter(Element element, @Nullable ClassLoader classLoader,
ParserContext parserContext) {
String filterType = element.getAttribute(FILTER_TYPE_ATTRIBUTE);
String expression = element.getAttribute(FILTER_EXPRESSION_ATTRIBUTE);
expression = parserContext.getReaderContext().getEnvironment().resolvePlaceholders(expression);
if ("annotation".equals(filterType)) {
// 如果我们想扫描自定义的注解，那可以使用这个annotation类型，expression填注解全限定名就好了
return new AnnotationTypeFilter((Class<Annotation>) ClassUtils.forName(expression, classLoader));
}
else if ("assignable".equals(filterType)) {
// 扫描配置的类及其子类，expression填类的全限定名就好了，这个也偶尔用到，主要用来指定扫描一些二方库的bean
return new AssignableTypeFilter(ClassUtils.forName(expression, classLoader));
}
else if ("aspectj".equals(filterType)) {
// 扫描切面表达式所匹配的类
return new AspectJTypeFilter(expression, classLoader);
}
else if ("regex".equals(filterType)) {
// 扫描正则表达式所匹配的类
return new RegexPatternTypeFilter(Pattern.compile(expression));
}
else if ("custom".equals(filterType)) {
// 自定义的过滤器，对应的类需要实现TypeFilter接口
Class<?> filterClass = ClassUtils.forName(expression, classLoader);
if (!TypeFilter.class.isAssignableFrom(filterClass)) {
throw new IllegalArgumentException(
"Class is not assignable to [" + TypeFilter.class.getName() + "]: " + expression);
}
return (TypeFilter) BeanUtils.instantiateClass(filterClass);
}
else {
throw new IllegalArgumentException("Unsupported filter type: " + filterType);
}
}
复制代码
好了， context:component-scan
标签的属性解析就告一段落了，我们主要记住 base-package
和 Filter
相关的就好了，其余的其实也用不太到，毕竟这个扫描的功能主要只需要确定需要 扫描哪些包
以及需要 关注哪些类
就好了。那么我们接下来再往回看一下，扫描器的扫描逻辑是怎么样的，同学们可以空降 ComponentScanBeanDefinitionParser#parse
，然后我们来看一下获取到 scanner
之后， scanner.doScan(basePackages)
的逻辑：
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
for (String basePackage : basePackages) {
// 找到所以扫描到的beanDefinition
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
// 获取beanName，要知道，我们使用注解的时候，其实是没有一个像xml标签属性那样的东西来获取name的
// 这里通过beanNameGenerator来获取了beanName，默认就是通过注解内的对应属性或者类名。感兴趣的同学可以看下 AnnotationBeanNameGenerator
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
// 删掉了一下不重要的属性的赋值
if (candidate instanceof AnnotatedBeanDefinition) {
// 里是处理类上的一些公共注解的地方，比如@Primary，@Lazy等
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
// 这个判断的大概意思就是，看一下我们扫描出来的beanDifinition是不是第一次注册
// 如果不是第一次注册就不会再注册了，是通过beanName来从IOC容器中找有没有一样的
if (checkCandidate(beanName, candidate)) {
// ...
// 注册bean，这个逻辑我们第一篇看过了，就不在看了，实际上就是把beanDefinition放入
// beanDefinitionMap和beanDefinitionNames这两个容器里面
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
复制代码
我们先看一下是怎么 AnnotationConfigUtils.processCommonDefinitionAnnotations()
中是怎么处理类上的注解的：
static void processCommonDefinitionAnnotations(AnnotatedBeanDefinition abd, AnnotatedTypeMetadata metadata) {
AnnotationAttributes lazy = attributesFor(metadata, Lazy.class);
if (lazy != null) {
abd.setLazyInit(lazy.getBoolean("value"));
}
else if (abd.getMetadata() != metadata) {
lazy = attributesFor(abd.getMetadata(), Lazy.class);
if (lazy != null) {
abd.setLazyInit(lazy.getBoolean("value"));
}
}
if (metadata.isAnnotated(Primary.class.getName())) {
abd.setPrimary(true);
}
AnnotationAttributes dependsOn = attributesFor(metadata, DependsOn.class);
if (dependsOn != null) {
abd.setDependsOn(dependsOn.getStringArray("value"));
}
AnnotationAttributes role = attributesFor(metadata, Role.class);
if (role != null) {
abd.setRole(role.getNumber("value").intValue());
}
AnnotationAttributes description = attributesFor(metadata, Description.class);
if (description != null) {
abd.setDescription(description.getString("value"));
}
}
复制代码
大聪明们肯定已经发现了，其实就是看一下类上面有没有对应的注解，然后把对应的属性塞入 beanDefinition
对象嘛。这岂不是可以说是跟 XML
解析获取 beanDefinition
时的流程 一模一样
的？
是的，其实不管是基于 注解
还是基于 xml
，都是把一些描述 bean
的信息，收集汇总到相应的 beanDefinition
中而已。而 beanDefinition
的属性决定了这个 bean
会怎么实例化，需要注入哪些属性等等等等。
收集信息来注解 beanDefinition
的途径可以有多种-- 甚至你自己写一个解析json格式文件的组件也不是不行
，但是结果都是 殊途同归
的。
从这也可以看出 spring
设计的强大，这种 模块化
的设计思想和对 单一职责原则
（比较直观的是各种委托模式，专业的事给专业的类做）和 开闭原则
（到我们现在讲到的地方：自定义标签的设计，在不触动原有核心逻辑的情况下，我们可以很简单的对 spring
做一些自定义的拓展）的实践，我们日常开发中是否也可以借鉴借鉴呢？
好了，感慨完了，我们继续回到源码，接下来我们具体看下扫描器是怎么扫描到那些被注解标记的类的（其实就是对之前注册的过滤器的应用）， findCandidateComponents()
中调用了 scanCandidateComponents()
，我们之间看 scanCandidateComponents()
：
// 去除掉了异常处理和日志打印
private Set<BeanDefinition> scanCandidateComponents(String basePackage) {
Set<BeanDefinition> candidates = new LinkedHashSet<>();
String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
resolveBasePackage(basePackage) + '/' + this.resourcePattern;
// 这一段逻辑极其复杂切对我们理解主流程没太大帮助，我们就不看了（主要是涉及到模糊匹配的文件寻找）
// 大概就是把所有符合的类文件找出来了
Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
for (Resource resource : resources) {
// 解析文件信息，加载到内存，这里看下去也贼复杂，都是一些字节码解析技术了
// 我们只需要知道这样操作一番后，这个MetadataReader能拿到我们这个类的所有信息就好了
MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
// 这里就是我们过滤器发挥作用的地方了，符合条件的类才会生成beanDefinition
if (isCandidateComponent(metadataReader)) {
ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
sbd.setResource(resource);
sbd.setSource(resource);
// 这里主要判断一下，我们匹配到的类是不是一个符合条件的bean
// 比如说如果我们注解打在接口上，这里就不会把这个beanDefinition加入返回的容器了
if (isCandidateComponent(sbd)) {
candidates.add(sbd);
}
}
}
return candidates;
}
// 过滤器判断是否是我们关注的类，逻辑很直观
protected boolean isCandidateComponent(MetadataReader metadataReader) throws IOException {
// 先判断的excludeFilters
for (TypeFilter tf : this.excludeFilters) {
if (tf.match(metadataReader, getMetadataReaderFactory())) {
return false;
}
}
// 再判断的includeFilters
for (TypeFilter tf : this.includeFilters) {
if (tf.match(metadataReader, getMetadataReaderFactory())) {
// 如果是我们关注的类，还需要处理类上面的@Conditional注解
// 这里不继续往下拓展了，我简单讲一下逻辑：
// 1.找到类上面所有的@Conditional簇的注解
// 2.实例化所有对应的Conditional类，并排序
// 3.依次调用所有condition.matches()，所有条件全部满足才返回true
// 具体细节同学们感兴趣可以自己看下
return isConditionMatch(metadataReader);
}
}
return false;
}
// 判断是否不是接口那些
protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
return (metadata.isIndependent() // 不是实例内部类 并且
&& (metadata.isConcrete() // 不是接口或者抽象类 或者
||
(metadata.isAbstract() && metadata.hasAnnotatedMethods(Lookup.class.getName()))));
// 是抽象类但是有些方法被@Lookup注解标记，这个之前有稍微提过，xml标签里那个lookup-method标签跟这个是一个意思，相当于把这个方法委托/代理给另一个bean了，所以即使是抽象类也是可以变成一个bean的 -> spring动态代理生成一个子类
}
复制代码
那么其实看到这里，我们已经明白了 context:component-scan
标签是怎么扫描，怎么支持 @Component
注解的了，但是细心的同学们可能已经发现了，现在我们确实能扫描 @Component
注解了，但是我们 bean
中那些属性是怎么 注入
的呢？ @Autowrite
、 @Resource
这些注解是怎么支持的呢？以及 @Configuration
、 @Bean
又是如何支持的呢？
预知后事如何，请看下篇博客，哈哈哈~
3. Filter匹配流程
本来不想写 Filter
的匹配流程的，因为其实不是主流程，不过想想还是写一下吧，不然有些同学可能会纠结。
主要讲一下我们用的比较多的 AnnotationTypeFilter
，先看一下 AnnotationTypeFilter
的构造器：
// 我们简单看一下AnnotationTypeFilter的构造器
public AnnotationTypeFilter(Class<? extends Annotation> annotationType) {
this(annotationType, true, false);
}
// 可以看到，我们扫描@Component注解时，是考虑源注解，且不考虑接口上的注解的
public AnnotationTypeFilter(
// 注解类型
Class<? extends Annotation> annotationType,
// 是否考虑源注解
boolean considerMetaAnnotations,
// 是否考虑接口
boolean considerInterfaces) {
// 第一个参数是是否考虑继承的注解
super(annotationType.isAnnotationPresent(Inherited.class), considerInterfaces);
this.annotationType = annotationType;
this.considerMetaAnnotations = considerMetaAnnotations;
}
复制代码
再看一下核心的 match
方法，这里也是一个模板方法模式：
// 先看顶层类
public abstract class AbstractTypeHierarchyTraversingFilter implements TypeFilter {
@Override
public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory)
throws IOException {
// 直接看当前类是否匹配 - 模板方法，由子类实现，默认返回了false
if (matchSelf(metadataReader)) {
return true;
}
// 提供一个通过className判断是否匹配的钩子
ClassMetadata metadata = metadataReader.getClassMetadata();
if (matchClassName(metadata.getClassName())) {
return true;
}
if (this.considerInherited) {
// 如果考虑继承的注解，则找到对应的父类
String superClassName = metadata.getSuperClassName();
if (superClassName != null) {
// 先看下子类有没有 单独判断父类是否匹配 的逻辑
Boolean superClassMatch = matchSuperClass(superClassName);
if (superClassMatch != null) {
// 有写这个逻辑则直接用这个返回结果了
if (superClassMatch.booleanValue()) {
return true;
}
}
else {
// 没有 单独判断父类是否匹配 的逻辑 则直接走当前这个匹配逻辑
if (match(metadata.getSuperClassName(), metadataReaderFactory)) {
return true;
}
}
}
}
if (this.considerInterfaces) {
// 如果考虑接口的注解，则找到对应的接口，因为接口是多个，所以要循环
// 逻辑和父类那里类似，不多讲了
for (String ifc : metadata.getInterfaceNames()) {
Boolean interfaceMatch = matchInterface(ifc);
if (interfaceMatch != null) {
if (interfaceMatch.booleanValue()) {
return true;
}
}
else {
if (match(ifc, metadataReaderFactory)) {
return true;
}
}
}
}
return false;
}
}
复制代码
再看一下 AnnotationTypeFilter
的几个核心方法：
public class AnnotationTypeFilter extends AbstractTypeHierarchyTraversingFilter {
protected boolean matchSelf(MetadataReader metadataReader) {
AnnotationMetadata metadata = metadataReader.getAnnotationMetadata();
// 类上有目标注解
return metadata.hasAnnotation(this.annotationType.getName()) ||
// 如果可以从源注解拿，则找一下类上面有没有源注解是和目标注解一样的
(this.considerMetaAnnotations && metadata.hasMetaAnnotation(this.annotationType.getName()));
}
protected Boolean matchSuperClass(String superClassName) {
return hasAnnotation(superClassName);
}
protected Boolean matchInterface(String interfaceName) {
return hasAnnotation(interfaceName);
}
@Nullable
protected Boolean hasAnnotation(String typeName) {
if (Object.class.getName().equals(typeName)) {
return false;
}
// 这个父类和接口的匹配逻辑居然只能匹配到jdk内置（java开头）的类
// 看来默认的实现应该是用来支持JSR标准的那些注解的
else if (typeName.startsWith("java")) {
// ... 不关注
}
return null;
}
}
复制代码
我们可以看到，我们默认的 AnnotationTypeFilter
是考虑源注解的，那么这个源注解到底是个什么东西呢？
public @interface Controller {
@AliasFor(annotation = Component.class)
String value() default "";
}
public @interface Service {
@AliasFor(annotation = Component.class)
String value() default "";
}
public @interface Repository {
@AliasFor(annotation = Component.class)
String value() default "";
}
复制代码
常见的就是这个东西啦 @AliasFor(annotation = Component.class)
，这也是为什么我们默认的includeFilters明明只注册了一个 @Component
类型的 AnnotationTypeFilter
，但是我们 @Service
等也能被扫描到的原因啦！我们构造的 AnnotationTypeFilter
是考虑源注解的！
三、实践
都说实践出真知，我们跟着源码分析了这么一大波，但是事实是不是如我们分析的那样呢？为了证实一下，这边我简单使用一下spring预留的拓展点。
1. 使用 context:component-scan
扫描自定义注解
我们首先需要自定义一个注解：
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface MyService {
}
复制代码
然后配置一下 context:component-scan
标签：
<context:component-scan base-package="com.xiaoxizi.spring">
<context:include-filter type="annotation" expression="com.xiaoxizi.spring.annotation.MyService"/>
</context:component-scan>
复制代码
为我们的业务类打上注解：
@Data
@MyService
public class MyAnnoClass {
public String username = "xiaoxizi";
}
复制代码
运行：
public void test1() {
applicationContext = new ClassPathXmlApplicationContext("spring.xml");
MyAnnoClass myAnnoClass = applicationContext.getBean(MyAnnoClass.class);
System.out.println(myAnnoClass);
}
复制代码
输出结果：
MyAnnoClass(username=xiaoxizi) 复制代码
说明我们的自定义注解扫描到了，并且成功生成了 beanDefinition
并实例化了 bean
！
2. 自定义标签
先创建一个具体标签的解析类，我们这边简单点，直接继承了 spring
内部的一个类：
public class SimpleBeanDefinitionParse extends AbstractSingleBeanDefinitionParser {
@Override
protected String getBeanClassName(final Element element) {
System.out.println("SimpleBeanDefinitionParse ... getBeanClassName()");
return element.getAttribute("className");
}
}
复制代码
然后创建一个 SimpleNamespaceHandler
：
public class SimpleNamespaceHandler extends NamespaceHandlerSupport {
@Override
public void init() {
System.out.println("SimpleNamespaceHandler ... init()");
this.registerBeanDefinitionParser("simpleBean", new SimpleBeanDefinitionParse());
}
}
复制代码
配置写入 META-INF/spring.handlers
文件：
http/://www.xiaoxize.com/schema/simple=com.xiaoxizi.spring.tag.SimpleNamespaceHandler 复制代码
xml
配置中使用：
<xiaoxizi:simple className="com.xiaoxizi.spring.bean.MyAnnoClass"/> <!-- 该标签对应的命名空间在xml文件头部beans标签中声明 --> <beans xmlns:xiaoxizi="http://www.xiaoxize.com/schema/simple" ... /> 复制代码
目标类：
@Data
// @MyService
public class MyAnnoClass {
public String username = "xiaoxizi";
}
复制代码
运行：
public void test1() {
applicationContext = new ClassPathXmlApplicationContext("spring.xml");
MyAnnoClass myAnnoClass = applicationContext.getBean(MyAnnoClass.class);
System.out.println(myAnnoClass);
}
复制代码
输出结果-各种报错，哈哈哈：
Caused by: org.xml.sax.SAXParseException; lineNumber: 21; columnNumber: 91; cvc-complex-type.2.4.c: 通配符的匹配很全面, 但无法找到元素 'xiaoxizi:simple' 的声明。 复制代码
emmmm，翻车车啦~这里还是卡了一会的，主要是对 xml
规范的不熟悉导致的，原来我们在声明命名空间的时候，还要声明并定义对应的 XSD
文件，（这里我自己写了一个 xsd
文件，并通过 idea
的配置引入了工作空间）像这样：
<xiaoxizi:simple className="com.xiaoxizi.spring.bean.MyAnnoClass"/>
<!-- 该标签对应的命名空间在xml文件头部beans标签中声明 -->
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xiaoxizi="http://www.xiaoxize.com/schema/simple"
xsi:schemaLocation="
http://www.xiaoxize.com/schema/simple
http://www.xiaoxize.com/schema/simple.xsd"
... />
复制代码
然后发现还是不行：
java.net.UnknownHostException: www.xiaoxize.com org.xml.sax.SAXParseException: schema_reference.4: 无法读取方案文档 'http://www.xiaoxize.com/schema/simple.xsd', 原因为 1) 无法找到文档; 2) 无法读取文档; 3) 文档的根元素不是 <xsd:schema>。 Caused by: org.xml.sax.SAXParseException; lineNumber: 21; columnNumber: 91; cvc-complex-type.2.4.c: 通配符的匹配很全面, 但无法找到元素 'xiaoxizi:simple' 的声明。 复制代码
啊，原来 spring
解析这个 xml
的时候，是不归 idea
管的，他还是会去对应的域名下找这个 xsd
文件（而我根本没有 xiaoxizi
这个域名...），最后我把 xsd
文件丢到自己服务器上，并且调整了域名那些，终于可以了：
SimpleNamespaceHandler ... init() SimpleBeanDefinitionParse ... getBeanClassName() MyAnnoClass(username=xiaoxizi) 复制代码
大功告成，所以自定义标签还是蛮简单的嘛（认真脸！
四、总结
1. 自定义标签解析过程
-
第一个自定义标签开始解析
时，将会从 所有
jar包的META-INF/spring.handlers文件加载 自定义标签命名空间-对应NamespaceHandler全限定名到内存中的DefaultNamespaceHandlerResolver.handlerMappings -
同样前缀
的自定义标签 第一次解析
时，将会实例化对应的
NamespaceHandler，并调用其init()方法，然后把自定义标签命名空间-对应NamespaceHandler实例放入handlerMappings，下次再有同样的标签过来解析，就直接能拿到对应的NamespaceHandler实例了 -
使用找到的
NamespaceHandler实例的parse方法解析自定义标签 -
spring贴心的为我们准备了NamespaceHandler相关的模版类NamespaceHandlerSupport，如果我们自定义的处理器继承了这个模版，那只需要在init方法中为具体的标签注入相应的BeanDefinitionParser或者BeanDefinitionDecorator就可以实现功能了
2. @Component
， @Service
等注解的实现原理
本来这一篇是打算讲完所有 context:component-scan
标签做的事情的，但是由于篇幅问题，没讲完，剩下的只能之后再讲了。
-
自定义标签
context:component-scan对应的解析器是ComponentScanBeanDefinitionParser（找的过程我们不赘述了）。 -
解析器的
parse方法中，我们通过标签配置的属性创建了一个 扫描器ClassPathBeanDefinitionScanner -
默认情况下， 我们会注册一个
@Component注解的AnnotationTypeFilter，并且注册到扫描器的includeFilters中 -
然后扫描器开始扫描
basePackage下所有的java类，并且找到所有不需要排除（excludeFilters）的候选类（includeFilters），然后为其生成一个beanDefinition，如果该类是一个合法的beanDefinition（非接口那些判断），那么就会将这些beanDefinition收集起来并返回 -
对于所有的候选
beanDefinition，扫描器还会进一步扫描类上的@Lazy、@Primary、@DependsOn等属性，然后设值到beanDefinition的对应属性中 -
最后一步，把我们所有扫描到的所有合法的
beanDefinition注册到IOC容器 -
由于
@Component是@Service、@Controller等注解的源注解，所以@Service这些注解标记的类也会被includeFilters扫描到
五、其他
实践中使用的的简单的 XSD
文件
<xsd:attribute name="className" type="xsd:string"></xsd:attribute>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://你的ip或者域名/simple"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://你的ip或者域名/simple"
elementFormDefault="qualified">
<xsd:element name="simple">
<xsd:complexType>
<xsd:attribute name="className" type="xsd:string"></xsd:attribute>
<xsd:attribute name="id" type="xsd:string"></xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:schema>
复制代码
这一篇写完感觉要把自己榨干了，好难写好多字...而且没有存稿了，之后的更新肯定会比较慢了~
正文到此结束
- 本文标签： 服务器 js 配置 CEO XML final 处理器 Collection synchronized root https map 域名 json 锁 ACE IO 字节码 java ip expat 空间 实例 开发 mmm cache equals spring db cat 设计模式 Document 参数 博客 ORM ConcurrentHashMap 目录 node description 代码 parse BeanUtils http ioc HashMap 正则表达式 源码 find 管理 解析 list ask bean token 自定义标签 classpath tar IDE App value schema Service id tag ssl 开发者 CTO key 总结 BeanDefinition 工作原理 HashSet
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
