前言
隨著Spring Boot 的日漸流行，應用裡的大部分配置都被隱藏了起來，我們僅需要關心真正的業務內容， Controller, Service, Repository，拿起鍵盤就是一通業務代碼的Coding，具體的Component Scan，View，PlaceHolder ... 都可以拋在腦後。但其實這種零配置在Java 應用開發中，還真不太久。 「由奢入儉難」，不少開發者都經歷過Spring XML 配置的冗長，再回到這種配置確實不好受。
但有些時候，由於配置的內容在Spring Boot這種零配置中並不能很好的實現，就需要我們仍使用XML 的配置形式，然後再ImportSource進來。或者一些項目受環境等影響，未使用Boot進行開發，此時也需要對配置有一定的了解。
那這次讓我們往回看一些，看看在XML 配置中，一些自定義的Schema 內容，是如何融合到Spring 中進行配置的。例如：
Spring data es
dubbo
還有許多這樣的例子，我們不再一一羅列。但通過上述兩個圖，我們發現一個共同的特點：
那這些自定義的配置，是在什麼時候工作的呢?如何校驗是否配置正確?
我們來看Spring 中包含一個名為spring.handlers的文件，所有的自定義擴展，都是通過這個文件生效的。 spring 官方的aop, tx 也都是這個原理。
這個文件在哪呢?
如上圖所示，是META-INF/spring.handlers。文件內容也超級簡單：
http/://www.springframework.org/schema/data/elasticsearch=org.springframework.data.elasticsearch.config.ElasticsearchNamespaceHandler
前面是各個schema前綴，後面是schema 對應的解析類。這個spring.handlers文件是什麼時候加載的呢?
這個也是發生在解析自定義配置文件過程中，有一個resolve的過程，此時會將當前classLoader對應的所有包含spring.handlers文件加載過來。
我們再來看這個解析類，內容如下：
public class ElasticsearchNamespaceHandler extends NamespaceHandlerSupport { public ElasticsearchNamespaceHandler() { } public void init() { RepositoryConfigurationExtension extension = new ElasticsearchRepositoryConfigExtension(); RepositoryBeanDefinitionParser parser = new RepositoryBeanDefinitionParser(extension); this.registerBeanDefinitionParser("repositories", parser); this.registerBeanDefinitionParser("node-client", new NodeClientBeanDefinitionParser()); this.registerBeanDefinitionParser("transport-client", new TransportClientBeanDefinitionParser()); } }首先是繼承自NamesapceHandlerSupport
然後在重寫的init方法中註冊了一系列的parser，每個parser對應一個字符串，就是我們在xml配置文件是使用的自定義內容，比如上面的es的配置
<elasticsearch:transport-client id="client" cluster-nodes="192.168.73.186:9300" cluster
這裡的配置最終就會通過TransportClientBeanDefinitionParser 來進行解析
而上面提到的各個parser，在init方法中，保存在了一個Map中
private final Map<String, BeanDefinitionParser> parsers = new HashMap();
所謂註冊parser，就是在向這個parsers的map進行put操作。
那回過頭來，在Spring中，最核心的內容是什麼呢? 是Bean。而實際上我們配置到XML裡的這些內容，最終也會生在一個對應的Bean,所有的配置，只是為了生成Bean，這些自定義的配置，都稱之為BeanDefinition。
所以，Spring 在解析配置文件是，會有如下的判斷，是否是defaultNamespace，不是的話就走customElementParse
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)) { this.parseDefaultElement(ele, delegate); } else { delegate.parseCustomElement(ele); } } } } else { delegate.parseCustomElement(root); } }而是不是defaultNameSpace的判斷更直接：namespace的uri有沒有內容，或者是不是spring 的beans的聲明
public boolean isDefaultNamespace(String namespaceUri) { return !StringUtils.hasLength(namespaceUri) || "http://www.springframework.org/schema/beans".equals(namespaceUri); }所以請求都走到了parseCustomElement裡，這裡開始進行配置的解析, parse的時候，通過uriResolver查到對應的Handler
public BeanDefinition parseCustomElement(Element ele, BeanDefinition containingBd) { String namespaceUri = this.getNamespaceURI(ele); NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri); if(handler == null) { this.error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele); return null; } else { return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd)); } }那此時返回的僅僅是spring.handlers裡配置的Handler，而每個Handler又註冊了不少的parse，還得需要一個獲取parser的過程
public BeanDefinition parse(Element element, ParserContext parserContext) { return this.findParserForElement(element, parserContext).parse(element, parserContext); } private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) { String localName = parserContext.getDelegate().getLocalName(element); BeanDefinitionParser parser = (BeanDefinitionParser)this.parsers.get(localName); if(parser == null) { parserContext.getReaderContext().fatal("Cannot locate BeanDefinitionParser for element [" + localName + "]", element); } return parser; }這個獲取的過程，就是通過傳入的string,在我們開始聲明的Map裡get對應的parser，再使用它進行配置的解析啦。
有了parser，後面就是生成BeanDefinition的過程。
我們看，這些parser，都是繼承自AbstraceBeanDefinitionParser，或者實現了BeanDefinitionParser 的接口，統一解析的入口處，是接口的parse方法。
public class TransportClientBeanDefinitionParser extends AbstractBeanDefinitionParser { public TransportClientBeanDefinitionParser() { } protected AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) { BeanDefinitionBuilder builder = BeanDefinitionBuilder.rootBeanDefinition(TransportClientFactoryBean.class); this.setConfigurations(element, builder); return this.getSourcedBeanDefinition(builder, element, parserContext); } }在重寫的parseInternal方法中，返回解析配置後對應的BeanDefinition。這裡也是各個框架自由抽象的地方。比如有些框架是簡單直接一個類，而有些在此處會應用一些類似策略、裝飾器等設計模式，提供更多的靈活性。
具體獲取到BeanDefinition之後，放到整個Context中如何生成Spring Bean的內容，以後我們再做分析。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對武林網的支持。