歡迎光臨
每天分享高質量文章

【死磕 Spring】—– IOC 之 獲取 Document 物件

點擊上方“Java技術驛站”,選擇“置頂公眾號”。

有內涵、有價值的文章第一時間送達!

精品專欄

 

XmlBeanDefinitionReader.doLoadDocument() 方法中做了兩件事情,一是呼叫 getValidationModeForResource() 獲取 XML 的驗證樣式,二是呼叫 DocumentLoader.loadDocument() 獲取 Document 物件。上篇博客已經分析了獲取 XML 驗證樣式(【死磕Spring】—– IOC 之 獲取驗證模型),這篇我們分析獲取 Document 物件。

獲取 Document 的策略由接口 DocumentLoader 定義,如下:

  1. public interface DocumentLoader {

  2.    Document loadDocument(

  3.            InputSource inputSource, EntityResolver entityResolver,

  4.            ErrorHandler errorHandler, int validationMode, boolean namespaceAware)

  5.            throws Exception;

  6. }

DocumentLoader 中只有一個方法 loadDocument() ,該方法接收五個引數:

  • inputSource:加載 Document 的 Resource 源

  • entityResolver:解析檔案的解析器

  • errorHandler:處理加載 Document 物件的過程的錯誤

  • validationMode:驗證樣式

  • namespaceAware:命名空間支持。如果要提供對 XML 名稱空間的支持,則為true

該方法由 DocumentLoader 的預設實現類 DefaultDocumentLoader 實現,如下:

  1.    public Document loadDocument(InputSource inputSource, EntityResolver entityResolver,

  2.            ErrorHandler errorHandler, int validationMode, boolean namespaceAware) throws Exception {

  3.        DocumentBuilderFactory factory = createDocumentBuilderFactory(validationMode, namespaceAware);

  4.        if (logger.isDebugEnabled()) {

  5.            logger.debug("Using JAXP provider [" + factory.getClass().getName() + "]");

  6.        }

  7.        DocumentBuilder builder = createDocumentBuilder(factory, entityResolver, errorHandler);

  8.        return builder.parse(inputSource);

  9.    }

首先呼叫 createDocumentBuilderFactory() 創建 DocumentBuilderFactory ,再通過該 factory 創建 DocumentBuilder,最後解析 InputSource 傳回 Document 物件。

EntityResolver

通過 loadDocument() 獲取 Document 物件時,有一個引數 entityResolver ,該引數是通過 getEntityResolver() 獲取的。

getEntityResolver() 傳回指定的解析器,如果沒有指定,則構造一個未指定的預設解析器。

  1.    protected EntityResolver getEntityResolver() {

  2.        if (this.entityResolver == null) {

  3.            ResourceLoader resourceLoader = getResourceLoader();

  4.            if (resourceLoader != null) {

  5.                this.entityResolver = new ResourceEntityResolver(resourceLoader);

  6.            }

  7.            else {

  8.                this.entityResolver = new DelegatingEntityResolver(getBeanClassLoader());

  9.            }

  10.        }

  11.        return this.entityResolver;

  12.    }

如果 ResourceLoader 不為 null,則根據指定的 ResourceLoader 創建一個 ResourceEntityResolver。如果 ResourceLoader 為null,則創建 一個 DelegatingEntityResolver,該 Resolver 委托給預設的 BeansDtdResolver 和 PluggableSchemaResolver 。

  • ResourceEntityResolver:繼承自 EntityResolver ,通過 ResourceLoader 來解析物體的取用。

  • DelegatingEntityResolver:EntityResolver 的實現,分別代理了 dtd 的 BeansDtdResolver 和 xml schemas 的 PluggableSchemaResolver。

  • BeansDtdResolver : spring bean dtd 解析器。EntityResolver 的實現,用來從 classpath 或者 jar 檔案加載 dtd。

  • PluggableSchemaResolver:使用一系列 Map 檔案將 schema url 解析到本地 classpath 資源

getEntityResolver() 傳回 EntityResolver ,那這個 EntityResolver 到底是什麼呢?

If a SAX application needs to implement customized handling for external entities, it must implement this interface and register an instance with the SAX driver using the setEntityResolver method.
就是說:如果 SAX 應用程式需要實現自定義處理外部物體,則必須實現此接口並使用 setEntityResolver() 向 SAX 驅動器註冊一個實體。

如下:

  1.   public class MyResolver implements EntityResolver {

  2.     public InputSource resolveEntity (String publicId, String systemId){

  3.       if (systemId.equals("http://www.myhost.com/today")){

  4.         MyReader reader = new MyReader();

  5.         return new InputSource(reader);

  6.       } else {

  7.            // use the default behaviour

  8.            return null;

  9.       }

  10.     }

  11.   }

我們首先將 spring-student.xml 檔案中的 XSD 宣告的地址改掉,如下:

如果我們再次運行,則會報如下錯誤:

從上面的錯誤可以看到,是在進行文件驗證時,無法根據宣告找到 XSD 驗證檔案而導致無法進行 XML 檔案驗證。在(【死磕Spring】----- IOC 之 獲取驗證模型)中講到,如果要解析一個 XML 檔案,SAX 首先會讀取該 XML 文件上的宣告,然後根據宣告去尋找相應的 DTD 定義,以便對文件進行驗證。預設的加載規則是通過網絡方式下載驗證檔案,而在實際生產環境中我們會遇到網絡中斷或者不可用狀態,那麼就應用就會因為無法下載驗證檔案而報錯。

EntityResolver 的作用就是應用本身可以提供一個如何尋找驗證檔案的方法,即自定義實現。

接口宣告如下:

  1. public interface EntityResolver {

  2.    public abstract InputSource resolveEntity (String publicId,String systemId)

  3.        throws SAXException, IOException;

  4. }

接口方法接收兩個引數 publicId 和 systemId,並傳回 InputSource 物件。兩個引數宣告如下:

  • publicId:被取用的外部物體的公共識別符號,如果沒有提供,則傳回null

  • systemId:被取用的外部物體的系統識別符號

這兩個引數的實際內容和具體的驗證樣式有關係。如下

  • XSD 驗證樣式

  • publicId:null

  • systemId:http://www.springframework.org/schema/beans/spring-beans.xsd

  • DTD 驗證樣式

  • publicId:-//SPRING//DTD BEAN 2.0//EN

  • systemId:http://www.springframework.org/dtd/spring-beans.dtd

如下:

我們知道在 Spring 中使用 DelegatingEntityResolver 為 EntityResolver 的實現類, resolveEntity()實現如下:

  1.    public InputSource resolveEntity(String publicId, @Nullable String systemId) throws SAXException, IOException {

  2.        if (systemId != null) {

  3.            if (systemId.endsWith(DTD_SUFFIX)) {

  4.                return this.dtdResolver.resolveEntity(publicId, systemId);

  5.            }

  6.            else if (systemId.endsWith(XSD_SUFFIX)) {

  7.                return this.schemaResolver.resolveEntity(publicId, systemId);

  8.            }

  9.        }

  10.        return null;

  11.    }

不同的驗證樣式使用不同的解析器解析,如果是 DTD 驗證樣式則使用 BeansDtdResolver 來進行解析,如果是 XSD 則使用 PluggableSchemaResolver 來進行解析。

BeansDtdResolver 的解析過程如下:

  1.    public InputSource resolveEntity(String publicId, @Nullable String systemId) throws IOException {

  2.        if (logger.isTraceEnabled()) {

  3.            logger.trace("Trying to resolve XML entity with public ID [" + publicId +

  4.                    "] and system ID [" + systemId + "]");

  5.        }

  6.        if (systemId != null && systemId.endsWith(DTD_EXTENSION)) {

  7.            int lastPathSeparator = systemId.lastIndexOf('/');

  8.            int dtdNameStart = systemId.indexOf(DTD_NAME, lastPathSeparator);

  9.            if (dtdNameStart != -1) {

  10.                String dtdFile = DTD_NAME + DTD_EXTENSION;

  11.                if (logger.isTraceEnabled()) {

  12.                    logger.trace("Trying to locate [" + dtdFile + "] in Spring jar on classpath");

  13.                }

  14.                try {

  15.                    Resource resource = new ClassPathResource(dtdFile, getClass());

  16.                    InputSource source = new InputSource(resource.getInputStream());

  17.                    source.setPublicId(publicId);

  18.                    source.setSystemId(systemId);

  19.                    if (logger.isDebugEnabled()) {

  20.                        logger.debug("Found beans DTD [" + systemId + "] in classpath: " + dtdFile);

  21.                    }

  22.                    return source;

  23.                }

  24.                catch (IOException ex) {

  25.                    if (logger.isDebugEnabled()) {

  26.                        logger.debug("Could not resolve beans DTD [" + systemId + "]: not found in classpath", ex);

  27.                    }

  28.                }

  29.            }

  30.        }

  31. or wherever.

  32.        return null;

  33.    }

從上面的代碼中我們可以看到加載 DTD 型別的 BeansDtdResolver.resolveEntity() 只是對 systemId 進行了簡單的校驗(從最後一個 / 開始,內容中是否包含 spring-beans),然後構造一個 InputSource 並設置 publicId、systemId,然後傳回。

PluggableSchemaResolver 的解析過程如下:

  1.    public InputSource resolveEntity(String publicId, @Nullable String systemId) throws IOException {

  2.        if (logger.isTraceEnabled()) {

  3.            logger.trace("Trying to resolve XML entity with public id [" + publicId +

  4.                    "] and system id [" + systemId + "]");

  5.        }

  6.        if (systemId != null) {

  7.            String resourceLocation = getSchemaMappings().get(systemId);

  8.            if (resourceLocation != null) {

  9.                Resource resource = new ClassPathResource(resourceLocation, this.classLoader);

  10.                try {

  11.                    InputSource source = new InputSource(resource.getInputStream());

  12.                    source.setPublicId(publicId);

  13.                    source.setSystemId(systemId);

  14.                    if (logger.isDebugEnabled()) {

  15.                        logger.debug("Found XML schema [" + systemId + "] in classpath: " + resourceLocation);

  16.                    }

  17.                    return source;

  18.                }

  19.                catch (FileNotFoundException ex) {

  20.                    if (logger.isDebugEnabled()) {

  21.                        logger.debug("Couldn't find XML schema [" + systemId + "]: " + resource, ex);

  22.                    }

  23.                }

  24.            }

  25.        }

  26.        return null;

  27.    }

首先呼叫 getSchemaMappings() 獲取一個映射表(systemId 與其在本地的對照關係),然後根據傳入的 systemId 獲取該 systemId 在本地的路徑 resourceLocation,最後根據 resourceLocation 構造 InputSource 物件。

映射表如下(部分):

【死磕 Spring】----- IOC 之 獲取驗證模型

【死磕 Spring】----- IOC 之 加載 Bean

【死磕 Spring】----- IOC 之 Spring 統一資源加載策略

【死磕 Spring】----- IOC 之深入理解 Spring IoC

END

赞(0)

分享創造快樂

© 2021 知識星球   网站地图