Spring源码初探-IOC(2)-Bean的初始化-自定义标签解析

前言

前面一文介绍的是Spring对于DefaultElement的解析，例如bean/import/alias等，但是在Spring体系中也存在很多扩展标签，例如事务、aop等非Default标签。按一般的套路通常是先介绍在Spring体系下如何在XML配置文件中自定义标签，本文先介绍Spring对于自定义标签的解析过程，在知道了Spring怎么“读”XML配置之后，写其能“读懂”的配置就显得非常自然了。

Spring自定义标签的解析过程

废话不多说了，先上图：

SpringIOC自定义标签解析过程.jpg

Delegate parseCustomElement

上篇介绍介绍了BeanDefinitionParserDelegate承担了大部分脏话累活，自定义标签的解析也是从BeanDefinitionParserDelegate开始进行。整个代码部分非常精简

public BeanDefinition parseCustomElement(Element ele, BeanDefinition containingBd) {   
String namespaceUri = getNamespaceURI(ele);   
NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri); 
  if (handler == null) { 
     error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);      return null;   }
   return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
}

NameSpaceUri与NameSpaceHandler

整个代码的逻辑就是先得到namespaceUri，然后namespaceUri查询到相应的NameSpaceHandler，利用handler.parse方法解析标签element。Spring的类的命名和方法命名基本可以等同于注释了，我们可能已经开始猜测每个NameSpaceUri会对应一个NamespaceHandler，然后NamespaceHandler会负责解析该NameSpace下自定义的所有标签。

但是NameSpaceUri是个什么鬼,我们可能都知道c++里面的namespace为了避免命名污染，在XML中一样的，为了避免命名冲突，同一个文档中可以出现多个同名标签，只要ns不一样，一般都会这么写<aop:user><tx:user>，虽然element都是user但是却属于不同的ns，那像aop，tx这种前缀是在哪里指定的呢，是在root标签里(最好是).例如beans标签中的 "xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mytag="http://www.w3school.com.cn/david/user" " 就是指定了命名空间，说了一大堆，那NameSpaceUri是什么鬼， “http://www.springframework.org/schema/beans” 就是NameSpaceUri

this.readerContext.getNamespaceHandlerResolver()

会得到一个NamespaceHandlerResolver，这个NamespaceHandlerResolver的实现类是DefaultNamespaceHandlerResolver，在其中会保存一个handlerMappings，就是<NamespaceUri,NamespaceHandler>的map集合，在Spring一启动的时候就会扫描/META-INF下所有名为spring.handlers的文件（貌似不区分这个文件的大小写，同时没有找到spring何时做的这个事情，但确实做了...），利用PropertiesUtil将其中的"a=b"分割，a为key，b为value放入handlerMappings，此时handlerMappings中的value还都只是对应Handler Class的类全名。在DefaultNamespaceHandlerResolver.resolve(NameSpaceUri)时首先从handlerMappings取出对应的value，如果已经是NameSpaceHanlder的子类对象了，则返回。如果还是String的ClassName则反射出对应的Class类对象，然后实例化一个对象，调用它的init()方法，将其放入handlerMappings中(key仍然是NameSpaceUri)，然后返回。说了一大堆，终于把如何获得对应NameSpaceUri的NamespaceHandler说明白了 接下来就是解释这句了

handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));

这句就是element的最终解析，delegate表示脏活累活再也不是我一个人干了，我还有handler这个小弟。handler嘿嘿一笑说，你还是navie呀，我也不怎么亲自干活的呢，我也将任务外包了喔。且看handler是怎么委派任务的吧！

NameSpaceHandler任务委派

NameSpaceHandler在parse的时候首先做的一件事情就是findParserForElement(在NameSpaceHandlerSupport中，Support意味助手，意思是告诉大家在自定义NameSpaceHandler时欢迎继承我，我会帮你做很多事情喔lol)，顾名思义，一个命名空间下可以定义很多个不同名标签，首先要找到这个element所对应的parser，类似于老板说“这个功能谁负责的？处理一下这是需求”。同样的，NameSpaceHandlerSupport中也保存了parser的Map,那如果是自定义的NameSpaceHandler，那按理说parserMap中不会有对应标签的Parser呀！答案就是在NameSpaceHandlerResolve中，会调用NameSpaceHandler的init()，一种方法就是你在init()中将<elementName,parser>put到parserMap中，但其实由于NameSpaceHandler是你自己定义的，你其实有很多种方法可以在findParserForElement之前将对应的<elementName,parser>put到parserMap中。在findParserForElement后，开始执行parseInternal方法，一路看下来都是在做准备工作，没有实质性的解析工作，其中出现了一个getBeanClass（)和getBeanClassName()，告诉parser你的element对应的Java类是啥。最后终于看到了doParse方法，按照经验来说，类中出现parse和doParse这样的一对方法，同时doParse还是用Protected，基本上可以断定这是模板模式或者策略模式。parse会将公共的解析逻辑抽取出来，将个性化的逻辑放入doParse，让子类实现个性化需求。最后调用parser的doParse方法完成相应的解析。最后像parseDefaultElement一样完成BeanDefinition的注册。

小结+如何实现自定义标签

洋洋洒洒写了一堆，小结一下。自定义标签设计到几个重要的类,NameSpaceHandler，BeanDefinitionParser。了解NameSpaceHandler和BeanDefinitionParser的过程就知道怎么自定义标签了，NameSpaceHandler的来源是spring会去扫描META-INF/spring.handlers的文件，所在在spring.handlers写清楚namespaceuri=namespacehanldername就行。同时由于XML验证机制有两种DTD和XSD，这里采用XSD，所以需要按照要求编写XSD文件，同时按照spring的要求，要在META-INF/spring.schemas文件中指定schema文件的位置。在就是需要写出NameSpaceHandler，可以通过集成NameSpaceHandlerSupport，最好是override init()方法完成初始化需求(例如put parser)，同时需要定义怎么解析，编写BeanDefinitionParser类，可以通过继承AbstractSingleBeanDefinitionParser或者AbstractBeanDefinitionParser，由于在调用时需要调用doParse和getBeanClass，请override这两个方法完成定制化解析！

TODO 给出实例