spring原始碼深度解析— IOC 之 容器的基本實現

chen_hao發表於2019-07-02

概述

上一篇我們搭建完Spring原始碼閱讀環境,spring原始碼深度解析—Spring的整體架構和環境搭建 這篇我們開始真正的閱讀Spring的原始碼,分析spring的原始碼之前我們先來簡單回顧下spring核心功能的簡單使用

容器的基本用法

bean是spring最核心的東西,spring就像是一個大水桶,而bean就是水桶中的水,水桶脫離了水也就沒有什麼用處了,我們簡單看下bean的定義,程式碼如下:

package com.chenhao.spring;

/**
 * @author: ChenHao
 * @Description:
 * @Date: Created in 10:35 2019/6/19
 * @Modified by:
 */
public class MyTestBean {
    private String name = "ChenHao";
public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

原始碼很簡單,bean沒有特別之處,spring的的目的就是讓我們的bean成為一個純粹的的POJO,這就是spring追求的,接下來就是在配置檔案中定義這個bean,配置檔案如下:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="myTestBean" class="com.chenhao.spring.MyTestBean"/>

</beans>

在上面的配置中我們可以看到bean的宣告方式,在spring中的bean定義有N種屬性,但是我們只要像上面這樣簡單的宣告就可以使用了。 
具體測試程式碼如下:

import com.chenhao.spring.MyTestBean;
import org.junit.Test;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;

/**
 * @author: ChenHao
 * @Description:
 * @Date: Created in 10:36 2019/6/19
 * @Modified by:
 */
public class AppTest {
    @Test
    public void MyTestBeanTest() {
        BeanFactory bf = new XmlBeanFactory( new ClassPathResource("spring-config.xml"));
        MyTestBean myTestBean = (MyTestBean) bf.getBean("myTestBean");
        System.out.println(myTestBean.getName());
    }
}

執行上述測試程式碼就可以看到輸出結果如下圖: 

其實直接使用BeanFactory作為容器對於Spring的使用並不多見,因為企業級應用專案中大多會使用的是ApplicationContext(後面我們會講兩者的區別,這裡只是測試)

功能分析

接下來我們分析2中程式碼完成的功能;
- 讀取配置檔案spring-config.xml。
- 根據spring-config.xml中的配置找到對應的類的配置,並例項化。
- 呼叫例項化後的例項
下圖是一個最簡單spring功能架構,如果想完成我們預想的功能,至少需要3個類: 

ConfigReader :用於讀取及驗證自己直檔案 我們妥用配直檔案裡面的東西,當然首先 要做的就是讀取,然後放直在記憶體中.

ReflectionUtil :用於根據配置檔案中的自己直進行反射例項化,比如在上例中 spring-config.xml 出現的<bean id="myTestBean" class="com.chenhao.spring.MyTestBean"/>,我們就可以根據 com.chenhao.spring.MyTestBean 進行例項化。

App :用於完成整個邏輯的串聯。

 工程搭建

spring的原始碼中用於實現上面功能的是spring-bean這個工程,所以我們接下來看這個工程,當然spring-core是必須的。

beans包的層級結構

閱讀原始碼最好的方式是跟著示例操作一遍,我們先看看beans工程的原始碼結構,如下圖所示: 

 

- src/main/java 用於展現Spring的主要邏輯 
- src/main/resources 用於存放系統的配置檔案 
- src/test/java 用於對主要邏輯進行單元測試 
- src/test/resources 用於存放測試用的配置檔案

核心類介紹

接下來我們先了解下spring-bean最核心的兩個類:DefaultListableBeanFactory和XmlBeanDefinitionReader

DefaultListableBeanFactory

XmlBeanFactory繼承自DefaultListableBeanFactory,而DefaultListableBeanFactory是整個bean載入的核心部分,是Spring註冊及載入bean的預設實現,而對於XmlBeanFactory與DefaultListableBeanFactory不同的地方其實是在XmlBeanFactory中使用了自定義的XML讀取器XmlBeanDefinitionReader,實現了個性化的BeanDefinitionReader讀取,DefaultListableBeanFactory繼承了AbstractAutowireCapableBeanFactory並實現了ConfigurableListableBeanFactory以及BeanDefinitionRegistry介面。以下是ConfigurableListableBeanFactory的層次結構圖以下相關類圖

上面類圖中各個類及介面的作用如下:
- AliasRegistry:定義對alias的簡單增刪改等操作
- SimpleAliasRegistry:主要使用map作為alias的快取,並對介面AliasRegistry進行實現
- SingletonBeanRegistry:定義對單例的註冊及獲取
- BeanFactory:定義獲取bean及bean的各種屬性
- DefaultSingletonBeanRegistry:預設對介面SingletonBeanRegistry各函式的實現
- HierarchicalBeanFactory:繼承BeanFactory,也就是在BeanFactory定義的功能的基礎上增加了對parentFactory的支援
- BeanDefinitionRegistry:定義對BeanDefinition的各種增刪改操作
- FactoryBeanRegistrySupport:在DefaultSingletonBeanRegistry基礎上增加了對FactoryBean的特殊處理功能
- ConfigurableBeanFactory:提供配置Factory的各種方法
- ListableBeanFactory:根據各種條件獲取bean的配置清單
- AbstractBeanFactory:綜合FactoryBeanRegistrySupport和ConfigurationBeanFactory的功能
- AutowireCapableBeanFactory:提供建立bean、自動注入、初始化以及應用bean的後處理器
- AbstractAutowireCapableBeanFactory:綜合AbstractBeanFactory並對介面AutowireCapableBeanFactory進行實現
- ConfigurableListableBeanFactory:BeanFactory配置清單,指定忽略型別及介面等
- DefaultListableBeanFactory:綜合上面所有功能,主要是對Bean註冊後的處理
XmlBeanFactory對DefaultListableBeanFactory類進行了擴充套件,主要用於從XML文件中讀取BeanDefinition,對於註冊及獲取Bean都是使用從父類DefaultListableBeanFactory繼承的方法去實現,而唯獨與父類不同的個性化實現就是增加了XmlBeanDefinitionReader型別的reader屬性。在XmlBeanFactory中主要使用reader屬性對資原始檔進行讀取和註冊

XmlBeanDefinitionReader

XML配置檔案的讀取是Spring中重要的功能,因為Spring的大部分功能都是以配置作為切入點的,可以從XmlBeanDefinitionReader中梳理一下資原始檔讀取、解析及註冊的大致脈絡,首先看看各個類的功能

ResourceLoader:定義資源載入器,主要應用於根據給定的資原始檔地址返回對應的Resource
BeanDefinitionReader:主要定義資原始檔讀取並轉換為BeanDefinition的各個功能
EnvironmentCapable:定義獲取Environment方法
DocumentLoader:定義從資原始檔載入到轉換為Document的功能
AbstractBeanDefinitionReader:對EnvironmentCapable、BeanDefinitionReader類定義的功能進行實現
BeanDefinitionDocumentReader:定義讀取Document並註冊BeanDefinition功能
BeanDefinitionParserDelegate:定義解析Element的各種方法
整個XML配置檔案讀取的大致流程,在XmlBeanDefinitionReader中主要包含以下幾步處理 

(1)通過繼承自AbstractBeanDefinitionReader中的方法,來使用ResourceLoader將資原始檔路徑轉換為對應的Resource檔案
(2)通過DocumentLoader對Resource檔案進行轉換,將Resource檔案轉換為Document檔案
(3)通過實現介面BeanDefinitionDocumentReader的DefaultBeanDefinitionDocumentReader類對Document進行解析,並使用BeanDefinitionParserDelegate對Element進行解析

容器的基礎XmlBeanFactory

 通過上面的內容我們對spring的容器已經有了大致的瞭解,接下來我們詳細探索每個步驟的詳細實現,接下來要分析的功能都是基於如下程式碼:

BeanFactory bf = new XmlBeanFactory( new ClassPathResource("spring-config.xml"));

首先呼叫ClassPathResource的建構函式來構造Resource資原始檔的例項物件,這樣後續的資源處理就可以用Resource提供的各種服務來操作了。有了Resource後就可以對BeanFactory進行初始化操作,那配置檔案是如何封裝的呢? 

配置檔案的封裝 

 Spring的配置檔案讀取是通過ClassPathResource進行封裝的,Spring對其內部使用到的資源實現了自己的抽象結構:Resource介面來封裝底層資源,如下原始碼:

public interface InputStreamSource {
    InputStream getInputStream() throws IOException;
}
public interface Resource extends InputStreamSource {
    boolean exists();
    default boolean isReadable() {
        return true;
    }
    default boolean isOpen() {
        return false;
    }
    default boolean isFile() {
        return false;
    }
    URL getURL() throws IOException;
    URI getURI() throws IOException;
    File getFile() throws IOException;
    default ReadableByteChannel readableChannel() throws IOException {
        return Channels.newChannel(getInputStream());
    }
    long contentLength() throws IOException;
    long lastModified() throws IOException;
    Resource createRelative(String relativePath) throws IOException;
    String getFilename();
    String getDescription();
}

 InputStreamSource封裝任何能返回InputStream的類,比如File、Classpath下的資源和Byte Array等, 它只有一個方法定義:getInputStream(),該方法返回一個新的InputStream物件 。

Resource介面抽象了所有Spring內部使用到的底層資源:File、URL、Classpath等。首先,它定義了3個判斷當前資源狀態的方法:存在性(exists)、可讀性(isReadable)、是否處於開啟狀態(isOpen)。另外,Resource介面還提供了不同資源到URL、URI、File型別的轉換,以及獲取lastModified屬性、檔名(不帶路徑資訊的檔名,getFilename())的方法,為了便於操作,Resource還提供了基於當前資源建立一個相對資源的方法:createRelative(),還提供了getDescription()方法用於在錯誤處理中的列印資訊。
對不同來源的資原始檔都有相應的Resource實現:檔案(FileSystemResource)、Classpath資源(ClassPathResource)、URL資源(UrlResource)、InputStream資源(InputStreamResource)、Byte陣列(ByteArrayResource)等,相關類圖如下所示: 

在日常開發中我們可以直接使用spring提供的類來載入資原始檔,比如在希望載入資原始檔時可以使用下面的程式碼:

Resource resource = new ClassPathResource("spring-config.xml");
InputStream is = resource.getInputStream();

有了 Resource 介面便可以對所有資原始檔進行統一處理 至於實現,其實是非常簡單的,以 getlnputStream 為例,ClassPathResource 中的實現方式便是通 class 或者 classLoader 提供的底層方法進行呼叫,而對於 FileSystemResource 其實更簡單,直接使用 FileInputStream 對檔案進行例項化。

ClassPathResource.java

InputStream is;
if (this.clazz != null) {
    is = this.clazz.getResourceAsStream(this.path);
}
else if (this.classLoader != null) {
    is = this.classLoader.getResourceAsStream(this.path);
}
else {
    is = ClassLoader.getSystemResourceAsStream(this.path);
}

FileSystemResource.java

public InputStream getinputStream () throws IOException {
    return new FilelnputStream(this file) ; 
}

當通過Resource相關類完成了對配置檔案進行封裝後,配置檔案的讀取工作就全權交給XmlBeanDefinitionReader來處理了。
接下來就進入到XmlBeanFactory的初始化過程了,XmlBeanFactory的初始化有若干辦法,Spring提供了很多的建構函式,在這裡分析的是使用Resource例項作為建構函式引數的辦法,程式碼如下:

XmlBeanFactory.java

public XmlBeanFactory(Resource resource) throws BeansException {
    this(resource, null);
}
public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws BeansException {
    super(parentBeanFactory);
    this.reader.loadBeanDefinitions(resource);
}

上面函式中的程式碼this.reader.loadBeanDefinitions(resource)才是資源載入的真正實現,但是在XmlBeanDefinitionReader載入資料前還有一個呼叫父類建構函式初始化的過程:super(parentBeanFactory),我們按照程式碼層級進行跟蹤,首先跟蹤到如下父類程式碼:

public DefaultListableBeanFactory(@Nullable BeanFactory parentBeanFactory) {
    super(parentBeanFactory);
}

然後繼續跟蹤,跟蹤程式碼到父類AbstractAutowireCapableBeanFactory的建構函式中:

public AbstractAutowireCapableBeanFactory(@Nullable BeanFactory parentBeanFactory) {
    this();
    setParentBeanFactory(parentBeanFactory);
}
public AbstractAutowireCapableBeanFactory() {
    super();
    ignoreDependencyInterface(BeanNameAware.class);
    ignoreDependencyInterface(BeanFactoryAware.class);
    ignoreDependencyInterface(BeanClassLoaderAware.class);
}

這裡有必要提及 ignoreDependencylnterface方法,ignoreDependencylnterface  的主要功能是 忽略給定介面的向動裝配功能,那麼,這樣做的目的是什麼呢?會產生什麼樣的效果呢?

舉例來說,當 A 中有屬性 B ,那麼當 Spring 在獲取 A的 Bean 的時候如果其屬性 B 還沒有 初始化,那麼 Spring 會自動初始化 B,這也是 Spring 提供的一個重要特性 。但是,某些情況 下, B不會被初始化,其中的一種情況就是B 實現了 BeanNameAware 介面 。Spring 中是這樣介紹的:自動裝配時忽略給定的依賴介面,典型應用是邊過其他方式解析 Application 上下文註冊依賴,類似於 BeanFactor 通過 BeanFactoryAware 進行注入或者 ApplicationContext 通過 ApplicationContextAware 進行注入。

呼叫ignoreDependencyInterface方法後,被忽略的介面會儲存在BeanFactory的名為ignoredDependencyInterfaces的Set集合中:

public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
        implements AutowireCapableBeanFactory {

    private final Set<Class<?>> ignoredDependencyInterfaces = new HashSet<>();
    
    public void ignoreDependencyInterface(Class<?> ifc) {
        this.ignoredDependencyInterfaces.add(ifc);
    }
...
}

ignoredDependencyInterfaces集合在同類中被使用僅在一處——isExcludedFromDependencyCheck方法中:

protected boolean isExcludedFromDependencyCheck(PropertyDescriptor pd) {
    return (AutowireUtils.isExcludedFromDependencyCheck(pd) || this.ignoredDependencyTypes.contains(pd.getPropertyType()) || AutowireUtils.isSetterDefinedInInterface(pd, this.ignoredDependencyInterfaces));
}

而ignoredDependencyInterface的真正作用還得看AutowireUtils類的isSetterDefinedInInterface方法。

public static boolean isSetterDefinedInInterface(PropertyDescriptor pd, Set<Class<?>> interfaces) {
    //獲取bean中某個屬性物件在bean類中的setter方法
    Method setter = pd.getWriteMethod();
    if (setter != null) {
        // 獲取bean的型別
        Class<?> targetClass = setter.getDeclaringClass();
        for (Class<?> ifc : interfaces) {
            if (ifc.isAssignableFrom(targetClass) && // bean型別是否介面的實現類
                ClassUtils.hasMethod(ifc, setter.getName(), setter.getParameterTypes())) { // 介面是否有入參和bean型別完全相同的setter方法
                return true;
            }
        }
    }
    return false;
}

ignoredDependencyInterface方法並不是讓我們在自動裝配時直接忽略實現了該介面的依賴。這個方法的真正意思是忽略該介面的實現類中和介面setter方法入參型別相同的依賴。
舉個例子。首先定義一個要被忽略的介面。

public interface IgnoreInterface {

    void setList(List<String> list);

    void setSet(Set<String> set);
}

然後需要實現該介面,在實現類中注意要有setter方法入參相同型別的域物件,在例子中就是List<String>和Set<String>。

public class IgnoreInterfaceImpl implements IgnoreInterface {

    private List<String> list;
    private Set<String> set;

    @Override
    public void setList(List<String> list) {
        this.list = list;
    }

    @Override
    public void setSet(Set<String> set) {
        this.set = set;
    }

    public List<String> getList() {
        return list;
    }

    public Set<String> getSet() {
        return set;
    }
}

定義xml配置檔案:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context.xsd"
default-autowire="byType">


    <bean id="list" class="java.util.ArrayList">
        <constructor-arg>
            <list>
                <value>foo</value>
                <value>bar</value>
            </list>
        </constructor-arg>
    </bean>

    <bean id="set" class="java.util.HashSet">
        <constructor-arg>
            <list>
                <value>foo</value>
                <value>bar</value>
            </list>
        </constructor-arg>
    </bean>

    <bean id="ii" class="com.chenhao.ignoreDependency.IgnoreInterfaceImpl"/>
    <bean class="com.chenhao.autowire.IgnoreAutowiringProcessor"/>
</beans>

最後呼叫ignoreDependencyInterface:

beanFactory.ignoreDependencyInterface(IgnoreInterface.class);

執行結果:
null
null
而如果不呼叫ignoreDependencyInterface,則是:
[foo, bar]
[bar, foo]

我們最初理解是在自動裝配時忽略該介面的實現,實際上是在自動裝配時忽略該介面實現類中和setter方法入參相同的型別,也就是忽略該介面實現類中存在依賴外部的bean屬性注入。

典型應用就是BeanFactoryAware和ApplicationContextAware介面。
首先看該兩個介面的原始碼:

public interface BeanFactoryAware extends Aware {
    void setBeanFactory(BeanFactory beanFactory) throws BeansException;
}

public interface ApplicationContextAware extends Aware {
    void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}

在Spring原始碼中在不同的地方忽略了該兩個介面:

beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);
ignoreDependencyInterface(BeanFactoryAware.class);

使得我們的BeanFactoryAware介面實現類在自動裝配時不能被注入BeanFactory物件的依賴:

public class MyBeanFactoryAware implements BeanFactoryAware {
    private BeanFactory beanFactory; // 自動裝配時忽略注入

    @Override
    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
        this.beanFactory = beanFactory;
    }

    public BeanFactory getBeanFactory() {
        return beanFactory;
    }
}

ApplicationContextAware介面實現類中的ApplicationContext物件的依賴同理:

public class MyApplicationContextAware implements ApplicationContextAware {
    private ApplicationContext applicationContext; // 自動裝配時被忽略注入

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    public ApplicationContext getApplicationContext() {
        return applicationContext;
    }
}
這樣的做法使得ApplicationContextAware和BeanFactoryAware中的ApplicationContext或BeanFactory依賴在自動裝配時被忽略,而統一由框架設定依賴,如ApplicationContextAware介面的設定會在ApplicationContextAwareProcessor類中完成:
private void invokeAwareInterfaces(Object bean) {
    if (bean instanceof Aware) {
        if (bean instanceof EnvironmentAware) {
            ((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
        }
        if (bean instanceof EmbeddedValueResolverAware) {
            ((EmbeddedValueResolverAware) bean).setEmbeddedValueResolver(this.embeddedValueResolver);
        }
        if (bean instanceof ResourceLoaderAware) {
            ((ResourceLoaderAware) bean).setResourceLoader(this.applicationContext);
        }
        if (bean instanceof ApplicationEventPublisherAware) {
            ((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
        }
        if (bean instanceof MessageSourceAware) {
            ((MessageSourceAware) bean).setMessageSource(this.applicationContext);
        }
        if (bean instanceof ApplicationContextAware) {
            ((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
        }
    }
}

通過這種方式保證了ApplicationContextAware和BeanFactoryAware中的容器保證是生成該bean的容器。

bean載入

在之前XmlBeanFactory建構函式中呼叫了XmlBeanDefinitionReader型別的reader屬性提供的方法this.reader.loadBeanDefinitions(resource),而這句程式碼則是整個資源載入的切入點,這個方法的時序圖如下: 

我們來梳理下上述時序圖的處理過程:
(1)封裝資原始檔。當進入XmlBeanDefinitionReader後首先對引數Resource使用EncodedResource類進行封裝
(2)獲取輸入流。從Resource中獲取對應的InputStream並構造InputSource
(3)通過構造的InputSource例項和Resource例項繼續呼叫函式doLoadBeanDefinitions,loadBeanDefinitions函式具體的實現過程: 

public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
    Assert.notNull(encodedResource, "EncodedResource must not be null");
    if (logger.isTraceEnabled()) {
        logger.trace("Loading XML bean definitions from " + encodedResource);
    }

    Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
    if (currentResources == null) {
        currentResources = new HashSet<>(4);
        this.resourcesCurrentlyBeingLoaded.set(currentResources);
    }
    if (!currentResources.add(encodedResource)) {
        throw new BeanDefinitionStoreException(
                "Detected cyclic loading of " + encodedResource + " - check your import definitions!");
    }
    try {
        InputStream inputStream = encodedResource.getResource().getInputStream();
        try {
            InputSource inputSource = new InputSource(inputStream);
            if (encodedResource.getEncoding() != null) {
                inputSource.setEncoding(encodedResource.getEncoding());
            }
            return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
        }
        finally {
            inputStream.close();
        }
    }
    ...
}

EncodedResource的作用是對資原始檔的編碼進行處理的,其中的主要邏輯體現在getReader()方法中,當設定了編碼屬性的時候Spring會使用相應的編碼作為輸入流的編碼,在構造好了encodeResource物件後,再次轉入了可複用方法loadBeanDefinitions(new EncodedResource(resource)),這個方法內部才是真正的資料準備階段,程式碼如下:

protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
        throws BeanDefinitionStoreException {
    try {
        // 獲取 Document 例項
        Document doc = doLoadDocument(inputSource, resource);
        // 根據 Document 例項****註冊 Bean資訊
        return registerBeanDefinitions(doc, resource);
    }
    ...
}

核心部分就是 try 塊的兩行程式碼。

  1. 呼叫 doLoadDocument() 方法,根據 xml 檔案獲取 Document 例項。
  2. 根據獲取的 Document 例項註冊 Bean 資訊

其實在doLoadDocument()方法內部還獲取了 xml 檔案的驗證模式。如下:

protected Document doLoadDocument(InputSource inputSource, Resource resource) throws Exception {
    return this.documentLoader.loadDocument(inputSource, getEntityResolver(), this.errorHandler,
            getValidationModeForResource(resource), isNamespaceAware());
}

呼叫 getValidationModeForResource() 獲取指定資源(xml)的驗證模式。所以 doLoadBeanDefinitions()主要就是做了三件事情。

1. 呼叫 getValidationModeForResource() 獲取 xml 檔案的驗證模式
2. 呼叫 loadDocument() 根據 xml 檔案獲取相應的 Document 例項。
3. 呼叫 registerBeanDefinitions() 註冊 Bean 例項。

獲取XML的驗證模式 

DTD和XSD區別 

DTD(Document Type Definition)即文件型別定義,是一種XML約束模式語言,是XML檔案的驗證機制,屬於XML檔案組成的一部分。DTD是一種保證XML文件格式正確的有效方法,可以通過比較XML文件和DTD檔案來看文件是否符合規範,元素和標籤使用是否正確。一個DTD文件包含:元素的定義規則,元素間關係的定義規則,元素可使用的屬性,可使用的實體或符合規則。
使用DTD驗證模式的時候需要在XML檔案的頭部宣告,以下是在Spring中使用DTD宣告方式的程式碼:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//Spring//DTD BEAN 2.0//EN" "http://www.Springframework.org/dtd/Spring-beans-2.0.dtd">

XML Schema語言就是XSD(XML Schemas Definition)。XML Schema描述了XML文件的結構,可以用一個指定的XML Schema來驗證某個XML文件,以檢查該XML文件是否符合其要求,文件設計者可以通過XML Schema指定一個XML文件所允許的結構和內容,並可據此檢查一個XML文件是否是有效的。

在使用XML Schema文件對XML例項文件進行檢驗,除了要宣告名稱空間外(xmlns=http://www.Springframework.org/schema/beans),還必須指定該名稱空間所對應的XML Schema文件的儲存位置,通過schemaLocation屬性來指定名稱空間所對應的XML Schema文件的儲存位置,它包含兩個部分,一部分是名稱空間的URI,另一部分就該名稱空間所標識的XML Schema檔案位置或URL地址(xsi:schemaLocation=”http://www.Springframework.org/schema/beans http://www.Springframework.org/schema/beans/Spring-beans.xsd“),程式碼如下:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="myTestBean" class="com.chenhao.spring.MyTestBean"/>

</beans>

驗證模式的讀取 

在spring中,是通過getValidationModeForResource方法來獲取對應資源的驗證模式,其原始碼如下:

protected int getValidationModeForResource(Resource resource) {
    int validationModeToUse = getValidationMode();
    if (validationModeToUse != VALIDATION_AUTO) {
        return validationModeToUse;
    }
    int detectedMode = detectValidationMode(resource);
    if (detectedMode != VALIDATION_AUTO) {
        return detectedMode;
    }
    // Hmm, we didn't get a clear indication... Let's assume XSD,
    // since apparently no DTD declaration has been found up until
    // detection stopped (before finding the document's root tag).
    return VALIDATION_XSD;
}

方法的實現還是很簡單的,如果設定了驗證模式則使用設定的驗證模式(可以通過使用XmlBeanDefinitionReader中的setValidationMode方法進行設定),否則使用自動檢測的方式。而自動檢測驗證模式的功能是在函式detectValidationMode方法中,而在此方法中又將自動檢測驗證模式的工作委託給了專門處理類XmlValidationModeDetector的validationModeDetector方法,具體程式碼如下:

public int detectValidationMode(InputStream inputStream) throws IOException {
    // Peek into the file to look for DOCTYPE.
    BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
    try {
        boolean isDtdValidated = false;
        String content;
        while ((content = reader.readLine()) != null) {
            content = consumeCommentTokens(content);
            if (this.inComment || !StringUtils.hasText(content)) {
                continue;
            }
            if (hasDoctype(content)) {
                isDtdValidated = true;
                break;
            }
            if (hasOpeningTag(content)) {
                // End of meaningful data...
                break;
            }
        }
        return (isDtdValidated ? VALIDATION_DTD : VALIDATION_XSD);
    }
    catch (CharConversionException ex) {
        // Choked on some character encoding...
        // Leave the decision up to the caller.
        return VALIDATION_AUTO;
    }
    finally {
        reader.close();
    }
}

從程式碼中看,主要是通過讀取 XML 檔案的內容,判斷內容中是否包含有 DOCTYPE ,如果是 則為 DTD,否則為 XSD,當然只會讀取到 第一個 “<” 處,因為 驗證模式一定會在第一個 “<” 之前。如果當中出現了 CharConversionException 異常,則為 XSD模式。

獲取Document

經過了驗證模式準備的步驟就可以進行Document載入了,對於文件的讀取委託給了DocumentLoader去執行,這裡的DocumentLoader是個介面,而真正呼叫的是DefaultDocumentLoader,解析程式碼如下:

public Document loadDocument(InputSource inputSource, EntityResolver entityResolver,
        ErrorHandler errorHandler, int validationMode, boolean namespaceAware) throws Exception {
    DocumentBuilderFactory factory = createDocumentBuilderFactory(validationMode, namespaceAware);
    if (logger.isDebugEnabled()) {
        logger.debug("Using JAXP provider [" + factory.getClass().getName() + "]");
    }
    DocumentBuilder builder = createDocumentBuilder(factory, entityResolver, errorHandler);
    return builder.parse(inputSource);
}

分析程式碼,首選建立DocumentBuildFactory,再通過DocumentBuilderFactory建立DocumentBuilder,進而解析InputSource來返回Document物件。對於引數entityResolver,傳入的是通過getEntityResolver()函式獲取的返回值,程式碼如下:

protected EntityResolver getEntityResolver() {
    if (this.entityResolver == null) {
        // Determine default EntityResolver to use.
        ResourceLoader resourceLoader = getResourceLoader();
        if (resourceLoader != null) {
            this.entityResolver = new ResourceEntityResolver(resourceLoader);
        }
        else {
            this.entityResolver = new DelegatingEntityResolver(getBeanClassLoader());
        }
    }
    return this.entityResolver;
}

這個entityResolver是做什麼用的呢,接下來我們詳細分析下。 

EntityResolver 的用法 

對於解析一個XML,SAX首先讀取該XML文件上的宣告,根據宣告去尋找相應的DTD定義,以便對文件進行一個驗證,預設的尋找規則,即通過網路(實現上就是宣告DTD的URI地址)來下載相應的DTD宣告,並進行認證。下載的過程是一個漫長的過程,而且當網路中斷或不可用時,這裡會報錯,就是因為相應的DTD宣告沒有被找到的原因.

EntityResolver的作用是專案本身就可以提供一個如何尋找DTD宣告的方法,即由程式來實現尋找DTD宣告的過程,比如將DTD檔案放到專案中某處,在實現時直接將此文件讀取並返回給SAX即可,在EntityResolver的介面只有一個方法宣告:

public abstract InputSource resolveEntity (String publicId, String systemId)
    throws SAXException, IOException;

它接收兩個引數publicId和systemId,並返回一個InputSource物件,以特定配置檔案來進行講解 
(1)如果在解析驗證模式為XSD的配置檔案,程式碼如下:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.Springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.Springframework.org/schema/beans http://www.Springframework.org/schema/beans/Spring-beans.xsd">
....
</beans>

則會讀取到以下兩個引數 
- publicId:null 
- systemId:http://www.Springframework.org/schema/beans/Spring-beans.xsd 

(2)如果解析驗證模式為DTD的配置檔案,程式碼如下:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//Spring//DTD BEAN 2.0//EN" "http://www.Springframework.org/dtd/Spring-beans-2.0.dtd">
....
</beans>

讀取到以下兩個引數
- publicId:-//Spring//DTD BEAN 2.0//EN
- systemId:http://www.Springframework.org/dtd/Spring-beans-2.0.dtd

一般都會把驗證檔案放置在自己的工程裡,如果把URL轉換為自己工程裡對應的地址檔案呢?以載入DTD檔案為例來看看Spring是如何實現的。根據之前Spring中通過getEntityResolver()方法對EntityResolver的獲取,我們知道,Spring中使用DelegatingEntityResolver類為EntityResolver的實現類,resolveEntity實現方法如下:

@Override
@Nullable
public InputSource resolveEntity(String publicId, @Nullable String systemId) throws SAXException, IOException {
    if (systemId != null) {
        if (systemId.endsWith(DTD_SUFFIX)) {
            return this.dtdResolver.resolveEntity(publicId, systemId);
        }
        else if (systemId.endsWith(XSD_SUFFIX)) {
            return this.schemaResolver.resolveEntity(publicId, systemId);
        }
    }
    return null;
}

不同的驗證模式使用不同的解析器解析,比如載入DTD型別的BeansDtdResolver的resolveEntity是直接擷取systemId最後的xx.dtd然後去當前路徑下尋找,而載入XSD型別的PluggableSchemaResolver類的resolveEntity是預設到META-INF/Spring.schemas檔案中找到systemId所對應的XSD檔案並載入。 BeansDtdResolver 的解析過程如下:

public InputSource resolveEntity(String publicId, @Nullable String systemId) throws IOException {
    if (logger.isTraceEnabled()) {
        logger.trace("Trying to resolve XML entity with public ID [" + publicId +
                "] and system ID [" + systemId + "]");
    }
    if (systemId != null && systemId.endsWith(DTD_EXTENSION)) {
        int lastPathSeparator = systemId.lastIndexOf('/');
        int dtdNameStart = systemId.indexOf(DTD_NAME, lastPathSeparator);
        if (dtdNameStart != -1) {
            String dtdFile = DTD_NAME + DTD_EXTENSION;
            if (logger.isTraceEnabled()) {
                logger.trace("Trying to locate [" + dtdFile + "] in Spring jar on classpath");
            }
            try {
                Resource resource = new ClassPathResource(dtdFile, getClass());
                InputSource source = new InputSource(resource.getInputStream());
                source.setPublicId(publicId);
                source.setSystemId(systemId);
                if (logger.isDebugEnabled()) {
                    logger.debug("Found beans DTD [" + systemId + "] in classpath: " + dtdFile);
                }
                return source;
            }
            catch (IOException ex) {
                if (logger.isDebugEnabled()) {
                    logger.debug("Could not resolve beans DTD [" + systemId + "]: not found in classpath", ex);
                }
            }
        }
    }
    return null;
}

從上面的程式碼中我們可以看到載入 DTD 型別的 BeansDtdResolver.resolveEntity() 只是對 systemId 進行了簡單的校驗(從最後一個 / 開始,內容中是否包含 spring-beans),然後構造一個 InputSource 並設定 publicId、systemId,然後返回。 PluggableSchemaResolver 的解析過程如下:

public InputSource resolveEntity(String publicId, @Nullable String systemId) throws IOException {
    if (logger.isTraceEnabled()) {
        logger.trace("Trying to resolve XML entity with public id [" + publicId +
                "] and system id [" + systemId + "]");
    }

    if (systemId != null) {
        String resourceLocation = getSchemaMappings().get(systemId);
        if (resourceLocation != null) {
            Resource resource = new ClassPathResource(resourceLocation, this.classLoader);
            try {
                InputSource source = new InputSource(resource.getInputStream());
                source.setPublicId(publicId);
                source.setSystemId(systemId);
                if (logger.isDebugEnabled()) {
                    logger.debug("Found XML schema [" + systemId + "] in classpath: " + resourceLocation);
                }
                return source;
            }
            catch (FileNotFoundException ex) {
                if (logger.isDebugEnabled()) {
                    logger.debug("Couldn't find XML schema [" + systemId + "]: " + resource, ex);
                }
            }
        }
    }
    return null;
}

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

 

解析及註冊BeanDefinitions

當把檔案轉換成Document後,接下來就是對bean的提取及註冊,當程式已經擁有了XML文件檔案的Document例項物件時,就會被引入到XmlBeanDefinitionReader.registerBeanDefinitions這個方法:

public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
    BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
    int countBefore = getRegistry().getBeanDefinitionCount();
    documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
    return getRegistry().getBeanDefinitionCount() - countBefore;
}

其中的doc引數即為上節讀取的document,而BeanDefinitionDocumentReader是一個介面,而例項化的工作是在createBeanDefinitionDocumentReader()中完成的,而通過此方法,BeanDefinitionDocumentReader真正的型別其實已經是DefaultBeanDefinitionDocumentReader了,進入DefaultBeanDefinitionDocumentReader後,發現這個方法的重要目的之一就是提取root,以便於再次將root作為引數繼續BeanDefinition的註冊,如下程式碼:

public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
    this.readerContext = readerContext;
    logger.debug("Loading bean definitions");
    Element root = doc.getDocumentElement();
    doRegisterBeanDefinitions(root);
}

通過這裡我們看到終於到了解析邏輯的核心方法doRegisterBeanDefinitions,接著跟蹤原始碼如下:

protected void doRegisterBeanDefinitions(Element root) {
    BeanDefinitionParserDelegate parent = this.delegate;
    this.delegate = createDelegate(getReaderContext(), root, parent);
    if (this.delegate.isDefaultNamespace(root)) {
        String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
        if (StringUtils.hasText(profileSpec)) {
            String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
                    profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
            if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
                if (logger.isInfoEnabled()) {
                    logger.info("Skipped XML bean definition file due to specified profiles [" + profileSpec +
                            "] not matching: " + getReaderContext().getResource());
                }
                return;
            }
        }
    }
    preProcessXml(root);
    parseBeanDefinitions(root, this.delegate);
    postProcessXml(root);
    this.delegate = parent;
}

我們看到首先要解析profile屬性,然後才開始XML的讀取,具體的程式碼如下:

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)) {
                    parseDefaultElement(ele, delegate);
                }
                else {
                    delegate.parseCustomElement(ele);
                }
            }
        }
    }
    else {
        delegate.parseCustomElement(root);
    }
}

最終解析動作落地在兩個方法處:parseDefaultElement(ele, delegate) 和 delegate.parseCustomElement(root)。我們知道在 Spring 有兩種 Bean 宣告方式:

  • 配置檔案式宣告:<bean id="myTestBean" class="com.chenhao.spring.MyTestBean"/>
  • 自定義註解方式:<tx:annotation-driven>

兩種方式的讀取和解析都存在較大的差異,所以採用不同的解析方法,如果根節點或者子節點採用預設名稱空間的話,則呼叫 parseDefaultElement() 進行解析,否則呼叫 delegate.parseCustomElement() 方法進行自定義解析。

而判斷是否預設名稱空間還是自定義名稱空間的辦法其實是使用node.getNamespaceURI()獲取名稱空間,並與Spring中固定的名稱空間http://www.springframework.org/schema/beans進行對比,如果一致則認為是預設,否則就認為是自定義。 

推薦部落格

  程式設計師寫程式碼之外,如何再賺一份工資?

profile的用法 

通過profile標記不同的環境,可以通過設定spring.profiles.active和spring.profiles.default啟用指定profile環境。如果設定了active,default便失去了作用。如果兩個都沒有設定,那麼帶有profiles的bean都不會生成。 

配置spring配置檔案最下面配置如下beans

<!-- 開發環境配置檔案 -->
<beans profile="development">
    <context:property-placeholder
            location="classpath*:config_common/*.properties, classpath*:config_development/*.properties"/>
</beans>

<!-- 測試環境配置檔案 -->
<beans profile="test">
    <context:property-placeholder
            location="classpath*:config_common/*.properties, classpath*:config_test/*.properties"/>
</beans>

<!-- 生產環境配置檔案 -->
<beans profile="production">
    <context:property-placeholder
            location="classpath*:config_common/*.properties, classpath*:config_production/*.properties"/>
</beans>

配置web.xml

<!-- 多環境配置 在上下文context-param中設定profile.default的預設值 -->
<context-param>
    <param-name>spring.profiles.default</param-name>
    <param-value>production</param-value>
</context-param>

<!-- 多環境配置 在上下文context-param中設定profile.active的預設值 -->
<!-- 設定active後default失效,web啟動時會載入對應的環境資訊 -->
<context-param>
    <param-name>spring.profiles.active</param-name>
    <param-value>test</param-value>
</context-param>

這樣啟動的時候就可以按照切換spring.profiles.active的屬性值來進行切換了。

相關文章