component是什么接口-尊龙游戏旗舰厅官网

上一篇我们讲了默认标签-bean标签的解析，今天我们讲一下自定义标签的解析。

这个问题其实上一篇有讲过，这边再复述一遍，在spring的xml配置文件中，我们可以把所有的标签分为两类：自定义标签和默认标签，区别如下

复制代码

需要注意的是，自定义标签的概念，并不完全只指我们开发时自己定义的标签，而是spring的开发者为之后拓展预留的拓展点，这个拓展点我们可以用，spring的开发人员在为spring添加新功能时，也可以使用。

我们现在的开发中，更多的情况下，其实是使用@configuration、@component、@service 等注解来进行bean的声明而不是使用xml的bean 标签了。

那么为什么一个类加上了这些注解之后，就能被spring管理了呢？

实际上这些拓展功能是spring通过自己预留的自定义标签的拓展点进行拓展的，对于上述的功能，具体是使用的context:component-scan标签。

我们今天就通过对自定义标签context:component-scan的解析来跟踪一下相应的源码，理解spring自定义标签解析的流程，同时也对context:component-scan实现的功能做一个讲解，看一下@component等标签的实现原理。

由于上一篇对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); }}@nullablepublic 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 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 gethandlermappings() { map 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.contextnamespacehandlerhttp://www.springframework.org/schema/jee=org.springframework.ejb.config.jeenamespacehandlerhttp://www.springframework.org/schema/lang=org.springframework.scripting.config.langnamespacehandlerhttp://www.springframework.org/schema/task=org.springframework.scheduling.config.tasknamespacehandlerhttp://www.springframework.org/schema/cache=org.springframework.cache.config.cachenamespacehandler复制代码

我们在回忆一下自定义标签的定义：

复制代码

可以看到我们的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对象，则此自定义标签无法解析，直接跳过)

接下来我们来看一下 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 parsers = new hashmap<>(); // 保存标签名-装饰器对应关系的容器 private final map decorators = new hashmap<>(); // 保存属性名-装饰器对应关系的容器 private final map 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 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)) { // 如果是标签则创建一个filter并加入includefilters typefilter typefilter = createtypefilter((element) node, classloader, parsercontext); scanner.addincludefilter(typefilter); } else if (exclude_filter_element.equals(localname)) { // 如果是标签则创建一个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) 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 doscan(string... basepackages) { for (string basepackage : basepackages) { // 找到所以扫描到的beandefinition set 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 scancandidatecomponents(string basepackage) { set 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动态代理生成一个子类}复制代码

本来不想写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是考虑源注解的！

看到这里，我们已经明白了context:component-scan标签是怎么扫描，怎么支持@component注解的了，但是细心的同学们可能已经发现了，现在我们确实能扫描@component注解了，但是我们bean中那些属性是怎么注入的呢？@autowrite、@resource这些注解是怎么支持的呢？以及@configuration、@bean又是如何支持的呢？

这些功能其实是在相应的beanpostprocessor中完成的，而这些beanpostprocessor的注册，也是在我们context:component-scan标签的解析过程中注入的。如果同学们还有印象的话，应该还记得componentscanbeandefinitionparser的parse方法中，我们再创建了扫描器并且进行扫描之后，还做了一些公共组件注册的工作：

public beandefinition parse(element element, parsercontext parsercontext) { // ... // 获取一个扫描器 - 这个东西很重要，我们以后还会看到 classpathbeandefinitionscanner scanner = configurescanner(parsercontext, element); // 嗯，扫描器进行扫描，看来就是这个方法会扫描那些注解了 set beandefinitions = scanner.doscan(basepackages); // 注册一些组件 registercomponents(parsercontext.getreadercontext(), beandefinitions, element); return null;}复制代码

我们看一下registercomponents方法：

protected void registercomponents( xmlreadercontext readercontext, set beandefinitions, element element) { // ... // register annotation config processors, if necessary. boolean annotationconfig = true; if (element.hasattribute(annotation_config_attribute)) { annotationconfig = boolean.parseboolean(element.getattribute(annotation_config_attribute)); } // 看下annotation-config配置，默认是为true的 if (annotationconfig) { set processordefinitions = // 注册一些支撑注解功能的processors annotationconfigutils.registerannotationconfigprocessors(readercontext.getregistry(), source); // ... } // ...}复制代码

那么到底注册了哪些processor呢？

public static set registerannotationconfigprocessors( beandefinitionregistry registry, @nullable object source) { // ... set beandefs = new linkedhashset<>(8); // 这里注册了一个configurationclasspostprocessor，顾名思义，这个应该是支撑@configuration相关的注解的 if (!registry.containsbeandefinition(configuration_annotation_processor_bean_name)) { rootbeandefinition def = new rootbeandefinition(configurationclasspostprocessor.class); def.setsource(source); // 注册逻辑registerpostprocessor beandefs.add(registerpostprocessor(registry, def, configuration_annotation_processor_bean_name)); } // 注册了一个autowiredannotationbeanpostprocessor，用来处理@autowire，@value注解的 if (!registry.containsbeandefinition(autowired_annotation_processor_bean_name)) { rootbeandefinition def = new rootbeandefinition(autowiredannotationbeanpostprocessor.class); def.setsource(source); beandefs.add(registerpostprocessor(registry, def, autowired_annotation_processor_bean_name)); } // check for jsr-250 support, and if present add the commonannotationbeanpostprocessor. // 这里是支撑jsr-250规范的@resource、@postconstruct、@predestroy注解的 if (jsr250present && !registry.containsbeandefinition(common_annotation_processor_bean_name)) { rootbeandefinition def = new rootbeandefinition(commonannotationbeanpostprocessor.class); def.setsource(source); beandefs.add(registerpostprocessor(registry, def, common_annotation_processor_bean_name)); } // check for jpa support, and if present add the persistenceannotationbeanpostprocessor. // 这里是支持注解形式的jpa的beanpostprocessor if (jpapresent && !registry.containsbeandefinition(persistence_annotation_processor_bean_name)) { rootbeandefinition def = new rootbeandefinition(); try { def.setbeanclass(classutils.forname(persistence_annotation_processor_class_name, annotationconfigutils.class.getclassloader())); } catch (classnotfoundexception ex) { throw new illegalstateexception( "cannot load optional framework class: " persistence_annotation_processor_class_name, ex); } def.setsource(source); beandefs.add(registerpostprocessor(registry, def, persistence_annotation_processor_bean_name)); } // 支撑spring-event相关注解的processor，对@eventlistener的支撑 if (!registry.containsbeandefinition(event_listener_processor_bean_name)) { rootbeandefinition def = new rootbeandefinition(eventlistenermethodprocessor.class); def.setsource(source); beandefs.add(registerpostprocessor(registry, def, event_listener_processor_bean_name)); } // 支撑spring-event相关注解的processor，对@eventlistener的支撑 if (!registry.containsbeandefinition(event_listener_factory_bean_name)) { rootbeandefinition def = new rootbeandefinition(defaulteventlistenerfactory.class); def.setsource(source); beandefs.add(registerpostprocessor(registry, def, event_listener_factory_bean_name)); } return beandefs;}复制代码

到此，context:component-scan标签所做的所有事情都做完了。它主要就是创建了一个扫描器来扫描我们基本的需要注册的bean，之后注册了一些支撑相应注解功能的processor，对于这些processor，我这边不会去单独讲解每个processor是什么时候被调用，怎么实现它的功能的，感兴趣的同学可以自行找到对应的类去看实现逻辑。

而之后讲bean初始化逻辑和生命周期的时候，我会在特定的拓展点，讲到一些processor的调用以及内部的逻辑，希望到时候同学们还能记起来这些processor是在哪里注册的。

都说实践出真知，我们跟着源码分析了这么一大波，但是事实是不是如我们分析的那样呢？为了证实一下，这边我简单使用一下spring预留的拓展点。

我们首先需要自定义一个注解：

@target({elementtype.type})@retention(retentionpolicy.runtime)public @interface myservice {}复制代码

然后配置一下context:component-scan标签：

复制代码

为我们的业务类打上注解：

@data@myservicepublic 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！

先创建一个具体标签的解析类，我们这边简单点，直接继承了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配置中使用：

复制代码

目标类：

@data// @myservicepublic 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的配置引入了工作空间)像这样：

复制代码

然后发现还是不行：

java.net.unknownhostexception: www.xiaoxize.comorg.xml.sax.saxparseexception: schema_reference.4: 无法读取方案文档 'http://www.xiaoxize.com/schema/simple.xsd', 原因为 1) 无法找到文档; 2) 无法读取文档; 3) 文档的根元素不是 。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)复制代码

大功告成，所以自定义标签还是蛮简单的嘛(认真脸！

第一个自定义标签开始解析时，将会从所有jar包的meta-inf/spring.handlers文件加载 自定义标签命名空间-对应namespacehandler全限定名到内存中的defaultnamespacehandlerresolver.handlermappings

同样前缀的自定义标签第一次解析时，将会实例化对应的namespacehandler，并调用其init()方法，然后把自定义标签命名空间-对应namespacehandler实例放入handlermappings，下次再有同样的标签过来解析，就直接能拿到对应的namespacehandler实例了

使用找到的namespacehandler实例的parse方法解析自定义标签

spring贴心的为我们准备了namespacehandler相关的模版类namespacehandlersupport，如果我们自定义的处理器继承了这个模版，那只需要在init方法中为具体的标签注入相应的beandefinitionparser或者beandefinitiondecorator就可以实现功能了

自定义标签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扫描到

注册一系列对@configuration、@autowired、@resource等注解进行支撑的processor

实践中使用的的简单的xsd文件

复制代码

多多支持，即可免费获取以上所有资料--转发 评论，关注我，私信口令 “java” ，(承诺100%免费)

希望大家将此篇文章分享，转载，让更多需要的朋友看到，这样不仅帮助了自己，也帮助了他人，谢谢！！

总结

以上是尊龙游戏旗舰厅官网为你收集整理的component是什么接口_逐行解读spring（二）什么，自定义标签没听说过？的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得尊龙游戏旗舰厅官网网站内容还不错，欢迎将尊龙游戏旗舰厅官网推荐给好友。