溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
前言
隨著 Spring Boot 的日漸流行，應(yīng)用里的大部分配置都被隱藏了起來(lái)，我們僅需要關(guān)心真正的業(yè)務(wù)內(nèi)容， Controller, Service, Repository，拿起鍵盤就是一通業(yè)務(wù)代碼的Coding，具體的 Component Scan，View，PlaceHolder ... 都可以拋在腦后。但其實(shí)這種零配置在 Java 應(yīng)用開發(fā)中，還真不太久。 「由奢入儉難」，不少開發(fā)者都經(jīng)歷過 Spring XML 配置的冗長(zhǎng)，再回到這種配置確實(shí)不好受。
但有些時(shí)候，由于配置的內(nèi)容在 Spring Boot這種零配置中并不能很好的實(shí)現(xiàn)，就需要我們?nèi)允褂?XML 的配置形式，然后再 ImportSource進(jìn)來(lái)?；蛘咭恍╉?xiàng)目受環(huán)境等影響，未使用Boot進(jìn)行開發(fā)，此時(shí)也需要對(duì)配置有一定的了解。
那這次讓我們往回看一些，看看在 XML 配置中，一些自定義的 Schema 內(nèi)容，是如何融合到 Spring 中進(jìn)行配置的。例如：
Spring data es
dubbo
還有許多這樣的例子，我們不再一一羅列。但通過上述兩個(gè)圖，我們發(fā)現(xiàn)一個(gè)共同的特點(diǎn)：
那這些自定義的配置，是在什么時(shí)候工作的呢?如何校驗(yàn)是否配置正確?
我們來(lái)看 Spring 中包含一個(gè)名為 spring.handlers的文件，所有的自定義擴(kuò)展，都是通過這個(gè)文件生效的。spring 官方的aop, tx 也都是這個(gè)原理。
這個(gè)文件在哪呢?
如上圖所示，是META-INF/spring.handlers。文件內(nèi)容也超級(jí)簡(jiǎn)單：
http\://www.springframework.org/schema/data/elasticsearch=org.springframework.data.elasticsearch.config.ElasticsearchNamespaceHandler
前面是各個(gè)schema前綴，后面是schema 對(duì)應(yīng)的解析類。這個(gè)spring.handlers文件是什么時(shí)候加載的呢?
這個(gè)也是發(fā)生在解析自定義配置文件過程中，有一個(gè)resolve的過程，此時(shí)會(huì)將當(dāng)前classLoader對(duì)應(yīng)的所有包含spring.handlers文件加載過來(lái)。
我們?cè)賮?lái)看這個(gè)解析類，內(nèi)容如下：
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方法中注冊(cè)了一系列的parser，每個(gè)parser對(duì)應(yīng)一個(gè)字符串，就是我們?cè)趚ml配置文件是使用的自定義內(nèi)容，比如上面的es的配置
<elasticsearch:transport-client id="client" cluster-nodes="192.168.73.186:9300" cluster
這里的配置最終就會(huì)通過 TransportClientBeanDefinitionParser 來(lái)進(jìn)行解析
而上面提到的各個(gè)parser，在init方法中，保存在了一個(gè)Map中
private final Map<String, BeanDefinitionParser> parsers = new HashMap();
所謂注冊(cè)parser，就是在向這個(gè)parsers的map進(jìn)行put操作。
那回過頭來(lái)，在Spring中，最核心的內(nèi)容是什么呢? 是Bean。而實(shí)際上我們配置到XML里的這些內(nèi)容，最終也會(huì)生在一個(gè)對(duì)應(yīng)的Bean,所有的配置，只是為了生成Bean，這些自定義的配置，都稱之為BeanDefinition。
所以，Spring 在解析配置文件是，會(huì)有如下的判斷，是否是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有沒有內(nèi)容，或者是不是spring 的beans的聲明
public boolean isDefaultNamespace(String namespaceUri) {
return !StringUtils.hasLength(namespaceUri) || "http://www.springframework.org/schema/beans".equals(namespaceUri);
}
所以請(qǐng)求都走到了parseCustomElement里，這里開始進(jìn)行配置的解析, parse的時(shí)候，通過uriResolver查到對(duì)應(yīng)的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));
}
}
那此時(shí)返回的僅僅是spring.handlers里配置的Handler，而每個(gè)Handler又注冊(cè)了不少的parse，還得需要一個(gè)獲取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;
}
這個(gè)獲取的過程，就是通過傳入的string,在我們開始聲明的Map里 get對(duì)應(yīng)的parser，再使用它進(jìn)行配置的解析啦。
有了parser，后面就是生成BeanDefinition的過程。
我們看，這些parser，都是繼承自AbstraceBeanDefinitionParser，或者實(shí)現(xiàn)了BeanDefinitionParser 的接口，統(tǒng)一解析的入口處，是接口的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方法中，返回解析配置后對(duì)應(yīng)的BeanDefinition。這里也是各個(gè)框架自由抽象的地方。比如有些框架是簡(jiǎn)單直接一個(gè)類，而有些在此處會(huì)應(yīng)用一些類似策略、裝飾器等設(shè)計(jì)模式，提供更多的靈活性。
具體獲取到BeanDefinition之后，放到整個(gè)Context中如何生成 Spring Bean的內(nèi)容，以后我們?cè)僮龇治觥?/p>
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)億速云的支持。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼