阅读之前要注意的东西：本文就是主打流水账式的源码阅读，主导的是一个参考，主要内容需要看官自己去源码中验证。全系列文章基于 spring 源码 5.x 版本。
引子
系列1 - bean 标签解析：
4、xml配置文件解析之【默认】命名空间【标签】的解析.md
5、xml配置文件解析之【自定义】命名空间【标签】的解析.md
系列2 - bean 获取: getBean() 做了什么
还是老规矩，先一句话概括本文干了啥：
因为入参给的是null，先忽略它。
super(parentFactory);
这里我们关注下，这里的 reader，它就是本文绝对的C位了，从名字就知道它干啥的了：
注意看 XmlBeanDefinitionReader 构造函数的入参，没错 XmlBeanFactory 被传进去了，不过这里被向上转型为：BeanDefinitionRegitry 接口类型了
由此可见，XmlBeanDefinitionReader 的解析结果，或者它的 后继者 的解析结果，最终肯定会注册到 XmlBeanFactory 上的。
不信走着瞧，后边一定能发现 某个地方在暗搓搓的调用 XmlBeanDefinitionReader.getRegistry() 方法，这时后你要知道 这里获取到对象，实质上就是我们的： XmlBeanFactory , 别问我为什么，你回过头去看类图就知道了。
下图的两行代码，分别就是下边 [第6] 和 [第7] 章节要讲述的内容：
下图做的事很好解释：
1.如果 "Bean 工厂" 预先配置了校验模式，将覆盖xml 中配置的 dtd 或 xsd 文件
在 XmlBeanFactory 的场景瞎， XmlBeanDefinitionReader 是 XmlBeanFactory 的成员变量。
除了 XmlBeanFactory 别的地方同样也会使用 XmlBeanDefinitionReader，区别是 XmlBeanFactory 只是使用了默认的 xml 校验。
如果我们反向跟踪瞎，谁调用过： setValidationMode() 方法，找到了下图中的：XmlWebApplicationContext ，这就说明在这个容器里，是支持动态设置xml校验模式的。
2.如果 "Bean工厂-BeanFactory" 没有预置 xml 校验模式，就会去扫描 xml 配置文件，读取其中配置的是：dtd 或者 xsd文件
看下图，就是个很鲜活的例子，这里使用的是 dtd
还是第五节的第一个图，我们进入 loadDocument 方法一探究竟：
this.documentLoader.loadDocument(xx,xxx,xx....)
实际上 documentLoader 这里是声明的接口，我们可以全局搜索一下，找到了它的唯一实现类：
最后进入到 loadDocument 方法
直到第6章为止，通过重重校验后，拿到了一个由原始 xml 配置文件封装的 Document 对象
本节要做的事就是从该 Document对象中，读取BeanDefinition 【Bean定义/配置信息】
老三样，根据接口定位它的实现类：
然后我们来到了此行的终点：
我们看这句代码，它把 xml 文档传进去了，也传了委托处理 "BeanDefinitioin" 的对象：delegate
parseBeanDefinitions(root, this.delegate);
我们还可以稍微再进去一丢丢：
下图中，我添加的注释里，提到了两个关键词：
默认命名空间：
自定义命名空间：
再往下就是 具体 xml 标签、元素的识别和解析了。暂时不用去深究它，到这里我们需要明白的是：
至于为什么我在第七章末尾说：xml最终的解析结果被 XmlBeanFactory （BeanDefinitionRegistry接口） 持有呢？
我们可以追溯下，XmlBeanFactory 在这个解析过程中，是怎么被逐步传递的。
前文提到过，在 XmlBeanFactory 类中初始化 reader 时调用了 XmlBeanDefinitionReader 的构造函数，这里已经把 XmlBeanFactory 自身作为参数传递进去了。
参数名为：
这个引用关系传递得非常隐蔽：
回过头去看 [第7章] 的第一个图，Document 的处理被委托给了一个别的类：
// 这里 documentReader 还特么是个局部变量
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
从这里可以得知，xml解析方法的调用链，已经离开 XmlBeanFactory.reader[XmlBeanDefinitionReader] 内部了；
只看这句代码，你会觉得 documentReader 只是一个在方法内部定义的局部变量，它解析完结果不就丢了么？
真的是这样吗，看下图的 createReaderContext 方法标注的内容：
没想到吧在这里， XmlBeanFactory.reader[XmlBeanDefinitionReader] 又一次被传下去了，所以引用链还是没断的，只是在不容易发现的地方，在默默的延续。
XmlBeanDefinitionReader.createReaderContext() 方法内，创建 XmlReaderContext 实例对象时，传递的 "this" 的 成员变量 registry 就是我们的 XmlBeanFactory 的对象实例。
xml解析方法的调用链，虽然已经离开 XmlBeanFactory.reader[XmlBeanDefinitionReader]，去到了 BeanDefinitionDocumentReader 内部，但是 XmlBeanFactory 也随着 BeanDefinitionDocumentReader 也悄悄的跟着去了。
到本文 [第7章] 的最后，Xml 的解析又被委托给了：
通过下边的两个图我们看看 BeanDefinitionParserDelegate 创建的时候都发生了什么：
先说说 parentDelegate = this.delegate，在我们当前场景下没有做出任何额外的配置动作，这里获取到的会是个空值：null
接着关注下： createDelegate() 方法的第一个参数：
它获取到的，就是上一节提到的，用 XmlBeanDefinitionReader 封装的 XmlReaderContext 对象。
在这里，可以认为， XmlBeanFactory 借道 XmlReaderContext 又一次悄悄的潜入到了, Xml 标签/元素 解析的 "代理类" 内部了。
XmlBeanFactory 真的是干特务的一把好手啊。
悄悄的进村，打枪的不要，哈哈。
最后的最后，当我们解析完成 xml 后要进行最终的注册时：需要经历如下的调用链才能拿到我们的：XmlBeanFactory 对象。
BeanDefinitionParserDelegate()
.XmlReaderContext()
.BeanDefinitionDocumentReader()
.XmlBeanFactory()
下一篇文章将会花一定篇幅，介绍spring的 xml 配置文件中定义的元素、标签的读取。