摘要：本文結合《Spring源碼深度解析》來分析Spring 5.0.6版本的源代碼。若有描述錯誤之處，歡迎指正。
在上一篇中提到過Spring中的標簽包括默認標簽和自定義標簽兩種，而兩種標簽的用法以及解析方式存在着很大的不同。本節開始詳細分析默認標簽的解析過程。
默認標簽的解析是在parseDefaultElement函數中進行的，函數中的功能邏輯一目了然，分別對4種不同標簽（import、alias、bean和beans）做了不同的處理。
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) { // 對import標簽的處理 if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) { importBeanDefinitionResource(ele); } // 對alias標簽的處理 else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) { processAliasRegistration(ele); } // 對bean標簽的處理 else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) { processBeanDefinition(ele, delegate); } // 對beans標簽的處理 else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) { // recurse doRegisterBeanDefinitions(ele); } }
在4種標簽中，對bean標簽的解析最為復雜也最為重要，所以從此標簽開始深入分析，如果能理解這個標簽的解析過程，其他標簽的解析就迎刃而解了。首先看看函數processBeanDefinition(ele, delegate)。
/** * Process the given bean element, parsing the bean definition * and registering it with the registry. */ protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) { BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele); if (bdHolder != null) { bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder); try { // Register the final decorated instance. BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry()); } catch (BeanDefinitionStoreException ex) { getReaderContext().error("Failed to register bean definition with name '" + bdHolder.getBeanName() + "'", ele, ex); } // Send registration event. getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder)); } }
乍一看，似乎一頭霧水，沒有以前的函數那樣清晰的邏輯。大致的邏輯總結如下。
（1）首先委托BeanDefinitionDelegate類的parseBeanDefinitionElement方法進行元素解析，返回BeanDefinitionHolder類型的實例bdHolder，經過這個方法后，bdHolder實例已經包含我們配置文件中配置的各種屬性了，例如class、name、id、alias之類的屬性。
（2）當返回的dbHolder不為空的情況下若存在默認標簽的子節點下再有自定義屬性，還需要再次對自定義標簽進行解析。
（3）解析完成后，需要對解析后的bdHolder進行注冊，同樣，注冊操作委托給了BeanDefinitionReaderUtils的registerBeanDefinition方法。
（4）最后發出響應事件，通知相關的監聽器，這個bean已經加載完成了。
配合時序圖，可能會更容易理解。
解析BeanDefinition
下面我們就針對各個操作做具體分析。首先我們從元素解析及信息提取開始，也就是BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele)，進入BeanDefinitionDelegate類的parseBeanDefinitionElement方法。
/** * Parses the supplied {@code <bean>} element. May return {@code null} * if there were errors during parse. Errors are reported to the * {@link org.springframework.beans.factory.parsing.ProblemReporter}. */ @Nullable public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) { return parseBeanDefinitionElement(ele, null); } /** * Parses the supplied {@code <bean>} element. May return {@code null} * if there were errors during parse. Errors are reported to the * {@link org.springframework.beans.factory.parsing.ProblemReporter}. */ @Nullable public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, @Nullable BeanDefinition containingBean) { // 解析id屬性 String id = ele.getAttribute(ID_ATTRIBUTE); // 解析name屬性 String nameAttr = ele.getAttribute(NAME_ATTRIBUTE); // 分割name屬性 List<String> aliases = new ArrayList<>(); if (StringUtils.hasLength(nameAttr)) { String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS); aliases.addAll(Arrays.asList(nameArr)); } String beanName = id; if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) { beanName = aliases.remove(0); if (logger.isDebugEnabled()) { logger.debug("No XML 'id' specified - using '" + beanName + "' as bean name and " + aliases + " as aliases"); } } if (containingBean == null) { checkNameUniqueness(beanName, aliases, ele); } AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean); if (beanDefinition != null) { if (!StringUtils.hasText(beanName)) { try { // 如果不存在beanName，那么根據Spring中提供的命名規則為當前bean生成對應的beanName if (containingBean != null) { beanName = BeanDefinitionReaderUtils.generateBeanName( beanDefinition, this.readerContext.getRegistry(), true); } else { beanName = this.readerContext.generateBeanName(beanDefinition); // Register an alias for the plain bean class name, if still possible, // if the generator returned the class name plus a suffix. // This is expected for Spring 1.2/2.0 backwards compatibility. String beanClassName = beanDefinition.getBeanClassName(); if (beanClassName != null && beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() && !this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) { aliases.add(beanClassName); } } if (logger.isDebugEnabled()) { logger.debug("Neither XML 'id' nor 'name' specified - " + "using generated bean name [" + beanName + "]"); } } catch (Exception ex) { error(ex.getMessage(), ele); return null; } } String[] aliasesArray = StringUtils.toStringArray(aliases); return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray); } return null; }
以上便是對默認標簽解析的全過程了。當然，對Spring的解析猶如洋蔥剝皮一樣，一層一層地進行，盡管現在只能看到對屬性id以及name的解析，但是很慶幸，思路我們已經了解了。在開始對屬性展開全面解析前，Spring在外層又做了一個當前層的功能架構，在當前層完成的主要工作包括如下內容。
（1）提取元素中的id以及name屬性。
（2）進一步解析其他所有屬性並統一封裝至GenericBeanDefinition類型的實例中。
（3）如果檢測到bean沒有指定beanName，那么使用默認規則為此Bean生成beanName。
（4）將獲取到的信息封裝到BeanDefinitionHolder的實例中。
我們進一步查看步驟（2）中對標簽其他屬性的解析過程。
/** * Parse the bean definition itself, without regard to name or aliases. May return * {@code null} if problems occurred during the parsing of the bean definition. */ @Nullable public AbstractBeanDefinition parseBeanDefinitionElement( Element ele, String beanName, @Nullable BeanDefinition containingBean) { this.parseState.push(new BeanEntry(beanName)); String className = null; // 解析class屬性 if (ele.hasAttribute(CLASS_ATTRIBUTE)) { className = ele.getAttribute(CLASS_ATTRIBUTE).trim(); } String parent = null; // 解析parent屬性 if (ele.hasAttribute(PARENT_ATTRIBUTE)) { parent = ele.getAttribute(PARENT_ATTRIBUTE); } try { // 創建用於承載屬性的AbstractBeanDefinition類型的GenericBeanDefinition AbstractBeanDefinition bd = createBeanDefinition(className, parent); // 硬編碼解析默認bean的各種屬性 parseBeanDefinitionAttributes(ele, beanName, containingBean, bd); // 提取description bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT)); // 解析元數據 parseMetaElements(ele, bd); // 解析lookup-method屬性 parseLookupOverrideSubElements(ele, bd.getMethodOverrides()); // 解析replaced-method parseReplacedMethodSubElements(ele, bd.getMethodOverrides()); // 解析構造函數參數 parseConstructorArgElements(ele, bd); // 解析property子元素 parsePropertyElements(ele, bd); // 解析qualifier子元素 parseQualifierElements(ele, bd); bd.setResource(this.readerContext.getResource()); bd.setSource(extractSource(ele)); return bd; } catch (ClassNotFoundException ex) { error("Bean class [" + className + "] not found", ele, ex); } catch (NoClassDefFoundError err) { error("Class that bean class [" + className + "] depends on not found", ele, err); } catch (Throwable ex) { error("Unexpected failure during bean definition parsing", ele, ex); } finally { this.parseState.pop(); } return null; }
終於，bean標簽的所有屬性，不論是常用的還是不常用的我們都看到了，盡管有些復雜的屬性還需要進一步的解析，不過絲毫不會影響我們興奮的心情。接下來，我們繼續一些復雜標簽屬性的解析。
1. 創建用於承載屬性的BeanDefinition
BeanDefinition是一個接口，在Spring中存在三種實現：RootBeanDefinition、ChildBeanDefinition以及GenericBeanDefinition。三種實現均繼承了AbstractBeanDefinition，其中BeanDefinition是配置文件<bean>元素標簽在容器中的內部表現形式。<bean>元素標簽擁有class、scope、lazy-init等配置屬性，BeanDefinition則提供了相應的beanClass、scope、lazyInit屬性，BeanDefinition和<bean>屬性是一一對應的。其中RootBeanDefinition是最常用的實現類，它對應一般的<bean>元素標簽，GenericBeanDefinition是自2.5版本以后新加入的bean文件配置屬性定義類，是一站式服務類。
在配置文件中可以定義父<bean>和子<bean>，父<bean>用RootBeanDefinition表示，而子<bean>用ChildBeanDefinition表示，而沒有父<bean>的<bean>就使用RootBeanDefinition表示。AbstractBeanDefinition對兩者共同的類信息進行抽象。
Spring通過BeanDefinition將配置文件中的<bean>配置信息轉換為容器的內部表示，並將這些BeanDefinition注冊到BeanDefinitionRegistry中。Spring容器的BeanDefinitionRegistry就像是Spring配置信息的內存數據庫，主要是以map的形式保存，后續操作直接從BeanDefinitionResistry中讀取配置信息。它們之間的關系如下圖所示：
因此，要解析屬性首先要創建用於承載屬性的實例，也就是創建GenericBeanDefinition類型的實例。而代碼createBeanDefinition(className, parent)的作用就是實現此功能。
/** * Create a bean definition for the given class name and parent name. * @param className the name of the bean class * @param parentName the name of the bean's parent bean * @return the newly created bean definition * @throws ClassNotFoundException if bean class resolution was attempted but failed */ protected AbstractBeanDefinition createBeanDefinition(@Nullable String className, @Nullable String parentName) throws ClassNotFoundException { return BeanDefinitionReaderUtils.createBeanDefinition( parentName, className, this.readerContext.getBeanClassLoader()); } /** * Create a new GenericBeanDefinition for the given parent name and class name, * eagerly loading the bean class if a ClassLoader has been specified. * @param parentName the name of the parent bean, if any * @param className the name of the bean class, if any * @param classLoader the ClassLoader to use for loading bean classes * (can be {@code null} to just register bean classes by name) * @return the bean definition * @throws ClassNotFoundException if the bean class could not be loaded */ public static AbstractBeanDefinition createBeanDefinition( @Nullable String parentName, @Nullable String className, @Nullable ClassLoader classLoader) throws ClassNotFoundException { GenericBeanDefinition bd = new GenericBeanDefinition(); // parentName可能為空 bd.setParentName(parentName); if (className != null) { if (classLoader != null) { // 如果classLoader不為空，則使用以傳入的classLoader加載類對象，否則只是記錄className bd.setBeanClass(ClassUtils.forName(className, classLoader)); } else { bd.setBeanClassName(className); } } return bd; }
2. 解析各種屬性
當我們創建了bean信息的承載實例后，便可以進行bean信息的各種屬性解析了，首先我們進入parseBeanDefinitionAttributes方法。parseBeanDefinitionAttributes方法是對element所有元素屬性進行解析：
/** * Apply the attributes of the given bean element to the given bean * definition. * @param ele bean declaration element * @param beanName bean name * @param containingBean containing bean definition * @return a bean definition initialized according to the bean element attributes */ public AbstractBeanDefinition parseBeanDefinitionAttributes(Element ele, String beanName, @Nullable BeanDefinition containingBean, AbstractBeanDefinition bd) { // 解析singleton屬性 // 檢查當前bean是否有singleton屬性，有則提示應該使用scope屬性，並拋出異常 if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) { error("Old 1.x 'singleton' attribute in use - upgrade to 'scope' declaration", ele); } // 解析scope屬性 else if (ele.hasAttribute(SCOPE_ATTRIBUTE)) { // 獲取並設置scope屬性值 bd.setScope(ele.getAttribute(SCOPE_ATTRIBUTE)); } else if (containingBean != null) { // Take default from containing bean in case of an inner bean definition. // 在嵌入beanDefinition情況下且沒有單獨指定scope屬性則使用父類默認的屬性 bd.setScope(containingBean.getScope()); } // 解析abstract屬性 if (ele.hasAttribute(ABSTRACT_ATTRIBUTE)) { bd.setAbstract(TRUE_VALUE.equals(ele.getAttribute(ABSTRACT_ATTRIBUTE))); } // 解析lazy-init屬性 String lazyInit = ele.getAttribute(LAZY_INIT_ATTRIBUTE); if (DEFAULT_VALUE.equals(lazyInit)) { lazyInit = this.defaults.getLazyInit(); } // 若沒有設置或設置成其他字符都會被設置為false bd.setLazyInit(TRUE_VALUE.equals(lazyInit)); // 解析autowire屬性 String autowire = ele.getAttribute(AUTOWIRE_ATTRIBUTE); bd.setAutowireMode(getAutowireMode(autowire)); // 解析depends-on屬性 if (ele.hasAttribute(DEPENDS_ON_ATTRIBUTE)) { String dependsOn = ele.getAttribute(DEPENDS_ON_ATTRIBUTE); bd.setDependsOn(StringUtils.tokenizeToStringArray(dependsOn, MULTI_VALUE_ATTRIBUTE_DELIMITERS)); } // 解析autowire-candidate屬性 String autowireCandidate = ele.getAttribute(AUTOWIRE_CANDIDATE_ATTRIBUTE); if ("".equals(autowireCandidate) || DEFAULT_VALUE.equals(autowireCandidate)) { String candidatePattern = this.defaults.getAutowireCandidates(); if (candidatePattern != null) { String[] patterns = StringUtils.commaDelimitedListToStringArray(candidatePattern); bd.setAutowireCandidate(PatternMatchUtils.simpleMatch(patterns, beanName)); } } else { bd.setAutowireCandidate(TRUE_VALUE.equals(autowireCandidate)); } // 解析primary屬性 if (ele.hasAttribute(PRIMARY_ATTRIBUTE)) { bd.setPrimary(TRUE_VALUE.equals(ele.getAttribute(PRIMARY_ATTRIBUTE))); } // 解析init-method屬性 if (ele.hasAttribute(INIT_METHOD_ATTRIBUTE)) { String initMethodName = ele.getAttribute(INIT_METHOD_ATTRIBUTE); bd.setInitMethodName(initMethodName); } else if (this.defaults.getInitMethod() != null) { bd.setInitMethodName(this.defaults.getInitMethod()); bd.setEnforceInitMethod(false); } // 解析destroy-method屬性 if (ele.hasAttribute(DESTROY_METHOD_ATTRIBUTE)) { String destroyMethodName = ele.getAttribute(DESTROY_METHOD_ATTRIBUTE); bd.setDestroyMethodName(destroyMethodName); } else if (this.defaults.getDestroyMethod() != null) { bd.setDestroyMethodName(this.defaults.getDestroyMethod()); bd.setEnforceDestroyMethod(false); } // 解析factory-method屬性 if (ele.hasAttribute(FACTORY_METHOD_ATTRIBUTE)) { bd.setFactoryMethodName(ele.getAttribute(FACTORY_METHOD_ATTRIBUTE)); } // 解析factory-bean屬性 if (ele.hasAttribute(FACTORY_BEAN_ATTRIBUTE)) { bd.setFactoryBeanName(ele.getAttribute(FACTORY_BEAN_ATTRIBUTE)); } return bd; }
我們可以清楚地看到Spring完成了對所有bean屬性的解析，這些屬性中有很多是我們經常使用的，同時我相信也一定會有或多或少的屬性是讀者不熟悉或是沒有使用過的，感興趣的讀者可以查閱相關資料進一步了解每個屬性。
3. 解析子元素meta
在開始解析元數據的分析前，我們先回顧下元數據meta屬性的使用。
<bean id="mySpringBean" class="org.cellphone.uc.MySpringBean"> <meta key="str" value="I'm a test attribute."/> </bean>
這段代碼並不會直接體現在MySpringBean的屬性當中，而是一個額外的聲明，當需要使用里面的信息的時候可以通過BeanDefinition的getAttribute(key)方法進行獲取。
對meta屬性的解析代碼如下：
public void parseMetaElements(Element ele, BeanMetadataAttributeAccessor attributeAccessor) { // 獲取當前節點的所有子元素 NodeList nl = ele.getChildNodes(); for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); // 提取meta if (isCandidateElement(node) && nodeNameEquals(node, META_ELEMENT)) { Element metaElement = (Element) node; String key = metaElement.getAttribute(KEY_ATTRIBUTE); String value = metaElement.getAttribute(VALUE_ATTRIBUTE); // 使用key、value構造BeanMetadataAttribute BeanMetadataAttribute attribute = new BeanMetadataAttribute(key, value); attribute.setSource(extractSource(metaElement)); // 記錄信息 attributeAccessor.addMetadataAttribute(attribute); } } }
4. 解析子元素lookup-method
同樣，子元素lookup-method似乎並不是很常用，但是在某些時候它的確是非常有用的屬性，通常我們稱它為獲取器注入。應用《Spring in Action》中的一句話：獲取器注入是一種特殊的方法注入，它是把一個方法聲明為返回某種類型的bean，但實際要返回的bean是在配置文件里面配置的，此方法可用在設計有些可插拔的功能上，接觸程序依賴。我們看看具體的應用。
（1）首先創建一個父類：
public class User { public void showMe() { System.out.println("I am a user"); } }
（2）創建其子類並覆蓋showMe方法：
public class Teacher extends User { @Override public void showMe() { System.out.println("I am a teacher"); } }
（3）創建調用方法：
public abstract class GetBeanTest { public void showMe() { this.getBean().showMe(); } public abstract User getBean(); }
（4）創建測試方法：
public class Main { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring/lookup-test.xml"); GetBeanTest getBeanTest = (GetBeanTest) context.getBean("getBeanTest"); getBeanTest.showMe(); } }
到現在為止，除了配置文件外，整個測試方法就完成了，如果之前沒有接觸過獲取器注入的讀者可能會有疑問：抽象方法還沒有被實現，怎么可以直接調用呢？答案就在Spring為我們提供的獲取器中，我們看看配置文件是怎么配置的。
<?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="getBeanTest" class="org.cellphone.uc.GetBeanTest"> <lookup-method name="getBean" bean="teacher"/> </bean> <bean id="teacher" class="org.cellphone.uc.Teacher"/> </beans>
在配置文件中，我們看到了源碼解析中提到的lookup-method子元素，這個配置完成的功能是動態地將teacher所代表的bean作為getBean的返回值，運行測試方法我們會看到控制台上的輸出：
I am a teacher
當我們的業務變更或者在其他情況下，teacher里面的業務邏輯已經不再符合我們的業務要求，需要進行替換怎么辦呢？這時我們需要增加新的邏輯類：
public class Student extends User { @Override public void showMe() { System.out.println("I am a student"); } }
同時修改配置文件：
<?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="getBeanTest" class="org.cellphone.uc.GetBeanTest"> <lookup-method name="getBean" bean="student"/> </bean> <bean id="teacher" class="org.cellphone.uc.Teacher"/> <bean id="student" class="org.cellphone.uc.Student"/> </beans>
再次運行測試類，你會發現不一樣的結果：
I am a student
至此，我們已經初步了解了lookup-method子元素所提供的大致功能，相信這時再次去看它的屬性提取源碼會覺得更有針對性。
/** * Parse lookup-override sub-elements of the given bean element. */ public void parseLookupOverrideSubElements(Element beanEle, MethodOverrides overrides) { NodeList nl = beanEle.getChildNodes(); for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); // 僅當在bean下面有子元素下且為lookup-method時有效 if (isCandidateElement(node) && nodeNameEquals(node, LOOKUP_METHOD_ELEMENT)) { Element ele = (Element) node; // 獲取要修飾的方法 String methodName = ele.getAttribute(NAME_ATTRIBUTE); // 獲取配置返回的bean String beanRef = ele.getAttribute(BEAN_ELEMENT); LookupOverride override = new LookupOverride(methodName, beanRef); override.setSource(extractSource(ele)); overrides.addOverride(override); } } }
上面的代碼很熟悉，似乎與parseMetaElements的代碼大同小異，最大的區別就是在if判斷中的節點名稱在這里被修改為LOOKUP_METHOD_ELEMENT。還有，在數據存儲上面通過使用LookupOverride類型的實體類來進行數據承載並記錄在AbstractBeanDefinition中的methodOverrides屬性中。
5. 解析子元素replaced-method
這個方法主要是對bean中replaced-method子元素的提取，在開始提取分析之前我們還是預先介紹下這個元素的用法。
方法替換：可以在運行時用新的方法替換現有的方法。與之前的lookup-method不同的是，replaced-method不但可以動態地替換返回實體bean，而且還能動態地更改原有方法的邏輯。我們來看看使用示例。
（1）在changeMe中完成某個業務邏輯：
public class UserChange { public void changeMe() { System.out.println("change me"); } }
（2）在運營一段時間后需要改變原有的業務邏輯：
public class UserChangeReplacer implements MethodReplacer { @Override public Object reimplement(Object obj, Method method, Object[] args) throws Throwable { System.out.println("我替換了原有的方法"); return null; } }
（3）使替換后的類生效：
<?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="userChange" class="org.cellphone.uc.UserChange"> <replaced-method name="changeMe" replacer="replacer"/> </bean> <bean id="replacer" class="org.cellphone.uc.UserChangeReplacer"/> </beans>
（4）測試：
public class ReplaceMain { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring/replace-test.xml"); UserChange change = (UserChange) context.getBean("userChange"); change.changeMe(); } }
好了，運行測試類就可以看到預期的效果了，控制台成功打印出“我替換了原有的方法”，也就是說我們做到了動態替換原有方法，知道了這個元素的用法，我們再次來看元素的提取過程：
/** * Parse replaced-method sub-elements of the given bean element. */ public void parseReplacedMethodSubElements(Element beanEle, MethodOverrides overrides) { NodeList nl = beanEle.getChildNodes(); for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); // 僅當在bean下面有子元素下且為replaced-method時有效 if (isCandidateElement(node) && nodeNameEquals(node, REPLACED_METHOD_ELEMENT)) { Element replacedMethodEle = (Element) node; // 提取要替換的舊的方法 String name = replacedMethodEle.getAttribute(NAME_ATTRIBUTE); // 提取對應的新的替換方法 String callback = replacedMethodEle.getAttribute(REPLACER_ATTRIBUTE); ReplaceOverride replaceOverride = new ReplaceOverride(name, callback); // Look for arg-type match elements. List<Element> argTypeEles = DomUtils.getChildElementsByTagName(replacedMethodEle, ARG_TYPE_ELEMENT); for (Element argTypeEle : argTypeEles) { // 記錄參數 String match = argTypeEle.getAttribute(ARG_TYPE_MATCH_ATTRIBUTE); match = (StringUtils.hasText(match) ? match : DomUtils.getTextValue(argTypeEle)); if (StringUtils.hasText(match)) { replaceOverride.addTypeIdentifier(match); } } replaceOverride.setSource(extractSource(replacedMethodEle)); overrides.addOverride(replaceOverride); } } }
我們可以看到無論是lookup-method還是replaced-method都是構造了一個MethodOverride，並最終記錄在了AbstractBeanDefinition中的methodOverrides屬性中。而這個屬性如何使用以完成它所提供的功能我們會在后續的章節進行詳細介紹。
6. 解析子元素constructor-arg
對構造函數的解析式非常常用，也是非常復雜的，下面舉個簡單的小例子：
<beans> <!-- 默認情況是按照參數的順序注入，當指定index索引后就可以改變注入參數的順序 --> <bean id= "helloBean" class="com.HelloBean"> <constructor-arg index="0"> <value>Hello</value> </cibstructor-arg> <constructor-arg index="1"> <value>World</value> </cibstructor-arg> </bean> </beans>
上面的配置是Spring構造函數配置中最基礎的配置，實現的功能就是對HelloBean自動尋找對應的構造函數，並在初始化的時候將設置的參數傳入。那么讓我們來看看具體的XML解析過程。
對於constructor-arg子元素的解析，Spring是通過parseConstructorArgElements函數來實現的，具體的代碼如下：
/** * Parse constructor-arg sub-elements of the given bean element. */ public void parseConstructorArgElements(Element beanEle, BeanDefinition bd) { NodeList nl = beanEle.getChildNodes(); for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); if (isCandidateElement(node) && nodeNameEquals(node, CONSTRUCTOR_ARG_ELEMENT)) { // 解析constructor-arg parseConstructorArgElement((Element) node, bd); } } }
這個結構中遍歷所有子元素，也就是提取所有constructor-arg，然后進行解析，具體的解析被放置在了另個函數parseConstructorArgElement中，
/** * Parse a constructor-arg element. */ public void parseConstructorArgElement(Element ele, BeanDefinition bd) { // 提取index屬性 String indexAttr = ele.getAttribute(INDEX_ATTRIBUTE); // 提取type屬性 String typeAttr = ele.getAttribute(TYPE_ATTRIBUTE); // 提取name屬性 String nameAttr = ele.getAttribute(NAME_ATTRIBUTE); if (StringUtils.hasLength(indexAttr)) { try { int index = Integer.parseInt(indexAttr); if (index < 0) { error("'index' cannot be lower than 0", ele); } else { try { this.parseState.push(new ConstructorArgumentEntry(index)); // 解析ele對應的屬性元素 Object value = parsePropertyValue(ele, bd, null); ConstructorArgumentValues.ValueHolder valueHolder = new ConstructorArgumentValues.ValueHolder(value); if (StringUtils.hasLength(typeAttr)) { valueHolder.setType(typeAttr); } if (StringUtils.hasLength(nameAttr)) { valueHolder.setName(nameAttr); } valueHolder.setSource(extractSource(ele)); // 不允許重復指定相同參數 if (bd.getConstructorArgumentValues().hasIndexedArgumentValue(index)) { error("Ambiguous constructor-arg entries for index " + index, ele); } else { bd.getConstructorArgumentValues().addIndexedArgumentValue(index, valueHolder); } } finally { this.parseState.pop(); } } } catch (NumberFormatException ex) { error("Attribute 'index' of tag 'constructor-arg' must be an integer", ele); } } else { // 沒有index屬性則自動尋找 try { this.parseState.push(new ConstructorArgumentEntry()); Object value = parsePropertyValue(ele, bd, null); ConstructorArgumentValues.ValueHolder valueHolder = new ConstructorArgumentValues.ValueHolder(value); if (StringUtils.hasLength(typeAttr)) { valueHolder.setType(typeAttr); } if (StringUtils.hasLength(nameAttr)) { valueHolder.setName(nameAttr); } valueHolder.setSource(extractSource(ele)); bd.getConstructorArgumentValues().addGenericArgumentValue(valueHolder); } finally { this.parseState.pop(); } } }
上面一段代碼涉及的邏輯並不復雜，首先是提取constructor-arg上必要的屬性（index、type、name）。
如果配置中指定了index屬性，那么操作步驟如下：
（1）解析constructor-arg的子元素。
（2）使用ConstructorArgumentValues.ValueHolder來封裝解析出來的元素。
（3）將type、name和index屬性一並封裝在ConstructorArgumentValues.ValueHolder中並添加至當前BeanDefinition的constructorArgumentValues的indexedArgumentValues屬性中。
如果沒有指定index屬性，那么操作步驟如下：
（1）解析constructor-arg的子元素。
（2）使用ConstructorArgumentValues.ValueHolder來封裝解析出來的元素。
（3）將type、name和index屬性一並封裝在ConstructorArgumentValues.ValueHolder中並添加至當前BeanDefinition的constructorArgumentValues的genericArgumentValues屬性中。
可以看到，對於是否定義index屬性，Spring的處理流程是不同的，關鍵在於屬性信息被保存的位置。
了解整個流程后，繼續嘗試了解解析構造函數配置中子元素的過程，進入parsePropertyValue：
/** * Get the value of a property element. May be a list etc. * Also used for constructor arguments, "propertyName" being null in this case. */ @Nullable public Object parsePropertyValue(Element ele, BeanDefinition bd, @Nullable String propertyName) { String elementName = (propertyName != null ? "<property> element for property '" + propertyName + "'" : "<constructor-arg> element"); // Should only have one child element: ref, value, list, etc. // 一個屬性只能對應一種類型：ref、value、list等 NodeList nl = ele.getChildNodes(); Element subElement = null; for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); // 對應description或者meta不處理 if (node instanceof Element && !nodeNameEquals(node, DESCRIPTION_ELEMENT) && !nodeNameEquals(node, META_ELEMENT)) { // Child element is what we're looking for. if (subElement != null) { error(elementName + " must not contain more than one sub-element", ele); } else { subElement = (Element) node; } } } // 解析constructor-arg上的ref屬性 boolean hasRefAttribute = ele.hasAttribute(REF_ATTRIBUTE); // 解析constructor-arg上的value屬性 boolean hasValueAttribute = ele.hasAttribute(VALUE_ATTRIBUTE); if ((hasRefAttribute && hasValueAttribute) || ((hasRefAttribute || hasValueAttribute) && subElement != null)) { /** * 在constructor-arg上不存在： * 1. 同時既有ref屬性又有value屬性 * 2. 存在ref屬性或者value屬性且又有子元素 */ error(elementName + " is only allowed to contain either 'ref' attribute OR 'value' attribute OR sub-element", ele); } if (hasRefAttribute) { // ref屬性的處理，使用RuntimeBeanReference封裝對應的ref名稱 String refName = ele.getAttribute(REF_ATTRIBUTE); if (!StringUtils.hasText(refName)) { error(elementName + " contains empty 'ref' attribute", ele); } RuntimeBeanReference ref = new RuntimeBeanReference(refName); ref.setSource(extractSource(ele)); return ref; } else if (hasValueAttribute) { // value屬性的處理，使用TypedStringValue封裝 TypedStringValue valueHolder = new TypedStringValue(ele.getAttribute(VALUE_ATTRIBUTE)); valueHolder.setSource(extractSource(ele)); return valueHolder; } else if (subElement != null) { // 解析子元素 return parsePropertySubElement(subElement, bd); } else { // Neither child element nor "ref" or "value" attribute found. // 既沒有ref也沒有value也沒有子元素，Spring蒙圈了 error(elementName + " must specify a ref or value", ele); return null; } }
從代碼上看，對構造函數中屬性元素的解析經歷了一下幾個過程。
（1）略過descrition或者meta。
（2）提取constructor-arg上的ref和value屬性，以便於根據規則驗證正確性，其規則為在constructor-arg上不存在以下情況。
-
同時既有ref屬性又有value屬性。
-
存在ref屬性或者value屬性且又有子元素。
（3）ref屬性的處理。使用RuntimeBeanReference封裝對應的ref名稱，如：
<constructor-arg ref = "hello" />
（4）value屬性的處理。使用TypedStringValue封裝，如：
<constructor-arg value = "hello" />
（5）子元素的處理。如：
<constructor-arg> <map> <entry key = "key" value = "value" /> </map> </constructor-arg>
而對於子元素的處理，例如這里提到的在構造函數中又嵌入了子元素map是怎么實現的呢？parsePropertySubElement中實現了對各種子元素的分類處理。
@Nullable public Object parsePropertySubElement(Element ele, @Nullable BeanDefinition bd) { return parsePropertySubElement(ele, bd, null); } /** * Parse a value, ref or collection sub-element of a property or * constructor-arg element. * @param ele subelement of property element; we don't know which yet * @param defaultValueType the default type (class name) for any * {@code <value>} tag that might be created */ @Nullable public Object parsePropertySubElement(Element ele, @Nullable BeanDefinition bd, @Nullable String defaultValueType) { if (!isDefaultNamespace(ele)) { return parseNestedCustomElement(ele, bd); } else if (nodeNameEquals(ele, BEAN_ELEMENT)) { BeanDefinitionHolder nestedBd = parseBeanDefinitionElement(ele, bd); if (nestedBd != null) { nestedBd = decorateBeanDefinitionIfRequired(ele, nestedBd, bd); } return nestedBd; } else if (nodeNameEquals(ele, REF_ELEMENT)) { // A generic reference to any name of any bean. String refName = ele.getAttribute(BEAN_REF_ATTRIBUTE); boolean toParent = false; if (!StringUtils.hasLength(refName)) { // A reference to the id of another bean in a parent context. // 解析parent refName = ele.getAttribute(PARENT_REF_ATTRIBUTE); toParent = true; if (!StringUtils.hasLength(refName)) { error("'bean' or 'parent' is required for <ref> element", ele); return null; } } if (!StringUtils.hasText(refName)) { error("<ref> element contains empty target attribute", ele); return null; } RuntimeBeanReference ref = new RuntimeBeanReference(refName, toParent); ref.setSource(extractSource(ele)); return ref; } // 對idref元素的解析 else if (nodeNameEquals(ele, IDREF_ELEMENT)) { return parseIdRefElement(ele); } // 對value子元素的解析 else if (nodeNameEquals(ele, VALUE_ELEMENT)) { return parseValueElement(ele, defaultValueType); } // 對null子元素的解析 else if (nodeNameEquals(ele, NULL_ELEMENT)) { // It's a distinguished null value. Let's wrap it in a TypedStringValue // object in order to preserve the source location. TypedStringValue nullHolder = new TypedStringValue(null); nullHolder.setSource(extractSource(ele)); return nullHolder; } else if (nodeNameEquals(ele, ARRAY_ELEMENT)) { // 解析array子元素 return parseArrayElement(ele, bd); } else if (nodeNameEquals(ele, LIST_ELEMENT)) { // 解析list子元素 return parseListElement(ele, bd); } else if (nodeNameEquals(ele, SET_ELEMENT)) { // 解析set子元素 return parseSetElement(ele, bd); } else if (nodeNameEquals(ele, MAP_ELEMENT)) { // 解析map子元素 return parseMapElement(ele, bd); } else if (nodeNameEquals(ele, PROPS_ELEMENT)) { // 解析props子元素 return parsePropsElement(ele); } else { error("Unknown property sub-element: [" + ele.getNodeName() + "]", ele); return null; } }
可以看到，在上面的函數中實現了所有可支持的子類的分類處理。
7. 解析子元素property
parsePropertyElements函數完成了對property屬性的提取，property使用方式如下：
<bean id = "test" class = "test.TestClass"> <property name = "testStr" value = "testStr" /> </bean>
具體的解析過程如下：
/** * Parse property sub-elements of the given bean element. */ public void parsePropertyElements(Element beanEle, BeanDefinition bd) { NodeList nl = beanEle.getChildNodes(); for (int i = 0; i < nl.getLength(); i++) { Node node = nl.item(i); if (isCandidateElement(node) && nodeNameEquals(node, PROPERTY_ELEMENT)) { parsePropertyElement((Element) node, bd); } } }
有了之前分析構造函數的經驗，這個函數並不難理解，無非是提取所有property的子元素，然后調用parsePropertyElement處理，parsePropertyElement代碼如下：
/** * Parse a property element. */ public void parsePropertyElement(Element ele, BeanDefinition bd) { String propertyName = ele.getAttribute(NAME_ATTRIBUTE); if (!StringUtils.hasLength(propertyName)) { error("Tag 'property' must have a 'name' attribute", ele); return; } this.parseState.push(new PropertyEntry(propertyName)); try { // 不允許多次對同一屬性配置 if (bd.getPropertyValues().contains(propertyName)) { error("Multiple 'property' definitions for property '" + propertyName + "'", ele); return; } Object val = parsePropertyValue(ele, bd, propertyName); PropertyValue pv = new PropertyValue(propertyName, val); parseMetaElements(ele, pv); pv.setSource(extractSource(ele)); bd.getPropertyValues().addPropertyValue(pv); } finally { this.parseState.pop(); } }
可以看到上面函數與構造函數注入方式不同的是將返回值使用PropertyValue進行封裝，並記錄在BeanDefinition中的propertyValues屬性中。
8. 解析子元素qualifier
對於qualifier元素的獲取，我們接觸更多的是注解的方式，在使用Spring框架中進行自動注入時，Spring容器中匹配的候選Bean數目必須有且只有一個。當找不到一個匹配的Bean時，Spring容器將拋出BeanCreationException異常，並指出必須至少擁有一個匹配的Bean。
Spring允許我們通過Qualifier指定注入Bean的名稱，這樣歧義就消除了，而對於配置方式使用如下：
<bean id="userChange" class="org.cellphone.uc.UserChange"> <qualifier type="org.springframework.beans.factory.annotation.Qualifier" value="uc"/> </bean>
其解析過程與之前大同小異，這里不再重復敘述。