背景简介

出现的原因

我们在阅读 Spring 源码时发现是有一些逻辑的：

Spring 在解析 XML 配置文件并创建 BD 注册时，逻辑如下：

1. 进行 XML 资源的加载
2. 进行 XML 文件的一些校验操作
3. 进行 XML 文件的解析，获得 DOM 树
4. 根据 DOM 树解析得到 BD

但是我们在第四步中解析 DOM 树中的每个节点时，分成两个分支：

• Spring 命名空间的节点，解析四个标签，得到基本的 BD 信息，然后调用注册的默认命名空间的解析器进行装饰
• 其他命名空间的节点，直接将整个解析工作委托给注册的此命名空间的解析器。

所以，如果想透彻了解 Spring 在创建 BD 的操作，并灵活定制解析，需要对解析器的实现规范、注册方法、及调用地点进行相关了解。

所以我们开始进行NamespaceHandlerResolver、NamespaceHandler相关接口的了解。我们本文着重介绍NamespaceHandlerResolver。

职责

NamespaceHandlerResolver负责进行不同命名空间的其解析器的注册。它规定了一个方法：根据命名空间获得解析器。

源码

/**
 * 在 DefaultBeanDefinitionDocumentReader 中用来管理命名空间的解析器注册及解析功能提供。
 * 
 * 他通过传入一个命名空间，穿出此命名空间对应的解析器来完成功能
 */
@FunctionalInterface
public interface NamespaceHandlerResolver {

    /**
     *
     * @param namespaceUri 命名空间
     * @return 对应的解析器
     */
    @Nullable
    NamespaceHandler resolve(String namespaceUri);

}

问题遗留

看样子这里只有getter没有setter。应该是在构造实例时穿进去的，在使用过程中不允许修改。后面看一下使用场景确认一下