欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Spring中自定義Schema如何解析生效詳解

 更新時間：2018年07月09日 09:34:01   作者：侯樹成  
Spring2.5在2.0的基于Schema的Bean配置的基礎(chǔ)之上，再增加了擴展XML配置的機制。通過該機制，我們可以編寫自己的Schema，并根據(jù)自定義的Schema用自定的標(biāo)簽配置Bean，下面這篇文章主要介紹了關(guān)于Spring中自定義Schema如何解析生效的相關(guān)資料，需要的朋友可以參考下

前言

隨著 Spring Boot 的日漸流行，應(yīng)用里的大部分配置都被隱藏了起來，我們僅需要關(guān)心真正的業(yè)務(wù)內(nèi)容， Controller, Service, Repository，拿起鍵盤就是一通業(yè)務(wù)代碼的Coding，具體的 Component Scan，View，PlaceHolder ... 都可以拋在腦后。但其實這種零配置在 Java 應(yīng)用開發(fā)中，還真不太久。 「由奢入儉難」，不少開發(fā)者都經(jīng)歷過 Spring XML 配置的冗長，再回到這種配置確實不好受。

但有些時候，由于配置的內(nèi)容在 Spring Boot這種零配置中并不能很好的實現(xiàn)，就需要我們?nèi)允褂?XML 的配置形式，然后再 ImportSource進來。或者一些項目受環(huán)境等影響，未使用Boot進行開發(fā)，此時也需要對配置有一定的了解。

那這次讓我們往回看一些，看看在 XML 配置中，一些自定義的 Schema 內(nèi)容，是如何融合到 Spring 中進行配置的。例如：

Spring data es


dubbo

還有許多這樣的例子，我們不再一一羅列。但通過上述兩個圖，我們發(fā)現(xiàn)一個共同的特點：

  • 都是通過schemaLocation將對應(yīng)的schema引入
  • 在對應(yīng)的beans元素中增加更具體的自定義配置

那這些自定義的配置，是在什么時候工作的呢?如何校驗是否配置正確?

我們來看 Spring 中包含一個名為 spring.handlers的文件，所有的自定義擴展，都是通過這個文件生效的。spring 官方的aop, tx 也都是這個原理。

這個文件在哪呢?

如上圖所示，是META-INF/spring.handlers。文件內(nèi)容也超級簡單：
http\://www.springframework.org/schema/data/elasticsearch=org.springframework.data.elasticsearch.config.ElasticsearchNamespaceHandler
前面是各個schema前綴，后面是schema 對應(yīng)的解析類。這個spring.handlers文件是什么時候加載的呢?

這個也是發(fā)生在解析自定義配置文件過程中，有一個resolve的過程，此時會將當(dāng)前classLoader對應(yīng)的所有包含spring.handlers文件加載過來。

我們再來看這個解析類，內(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方法中注冊了一系列的parser，每個parser對應(yīng)一個字符串，就是我們在xml配置文件是使用的自定義內(nèi)容，比如上面的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中，最核心的內(nèi)容是什么呢? 是Bean。而實際上我們配置到XML里的這些內(nèi)容，最終也會生在一個對應(yīng)的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有沒有內(nèi)容，或者是不是spring 的beans的聲明

public boolean isDefaultNamespace(String namespaceUri) { 
 return !StringUtils.hasLength(namespaceUri) || "http://www.springframework.org/schema/beans".equals(namespaceUri); 
 }

所以請求都走到了parseCustomElement里，這里開始進行配置的解析, parse的時候，通過uriResolver查到對應(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)); 
 } 
 }

那此時返回的僅僅是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對應(yīng)的parser，再使用它進行配置的解析啦。
有了parser，后面就是生成BeanDefinition的過程。

我們看，這些parser，都是繼承自AbstraceBeanDefinitionParser，或者實現(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方法中，返回解析配置后對應(yīng)的BeanDefinition。這里也是各個框架自由抽象的地方。比如有些框架是簡單直接一個類，而有些在此處會應(yīng)用一些類似策略、裝飾器等設(shè)計模式，提供更多的靈活性。

具體獲取到BeanDefinition之后，放到整個Context中如何生成 Spring Bean的內(nèi)容，以后我們再做分析。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

相關(guān)文章

最新評論