随着SpringBoot越来越流行，应用中的大部分配置都被隐藏起来了，我们只需要关心真正的业务内容，Controller，Service，Repository，拿起keyboard是一个业务代码的编码，具体的ComponentScan、View、PlaceHolder……都可以留下。但实际上，这种零配置在Java应用开发中并不算长。“由奢入俭难”，很多开发者都体验过冗长的SpringXML配置，再回到这种配置，着实难受。但是有的时候，因为配置的内容在SpringBoot的零配置中不能很好的实现，所以我们还是需要使用XML的配置形式，然后ImportSource进来。或者一些项目受环境影响等等，以及不是使用Boot开发的。这时候也需要对配置有一定的了解。这次我们回过头来看，XML配置中是如何将一些自定义的Schema内容集成到Spring中进行配置的。比如：Springdataesdubbo这样的例子很多，我们就不一一列举了。但是通过上面两张图，我们发现了一个共同的特点：都是通过schemaLocation引入对应的schema，并在对应的bean元素上添加更具体的自定义配置。这些自定义配置何时起作用？?如何查看配置是否正确？我们看Spring中包含一个名为spring.handlers的文件，所有的自定义扩展都是通过这个文件生效的。spring官方的aop和tx也是基于这个原理。这个文件在哪里？如上图所示，就是META-INF/spring.handlers。文件内容也超级简单：http\://www.springframework.org/schema/data/elasticsearch=org.springframework.data.elasticsearch.config.ElasticsearchNamespaceHandler前面是每个schema前缀，后面是解析类对应于模式。什么时候加载spring.handlers文件？在解析自定义配置文件的过程中也会出现这种情况。有一个解决过程。此时会加载当前classLoader对应的所有spring.handlers文件。我们再来看这个解析类，内容如下：publicclassElasticsearchNamespaceHandlerextendsNamespaceHandlerSupport{publicElasticsearchNamespaceHandler(){}publicvoidinit(){RepositoryConfigurationExtensionextension=newElasticsearchRepositoryConfigExtension();RepositoryBeanDefinitionParserparser=newRepositoryBeanDefinitionParser(extension);this.registerBeanDefinitionParser("repositories",parser);this.registerBeanDefinitionParser("节点客户端",newNodeClientBeanDefinitionParser());this.registerBeanDefinitionParser("transport-client",newTransportClientBeanDefinitionParser());}}首先继承了NamesapceHandlerSupport，然后在重写的init方法中注册了一系列解析器，每个解析器对应一个字符串，就是我们在xml配置文件，比如上面的es配置
