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 给出实例

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

如何把SQLMap里的功能移植到自己的程序中?

不知道各位有没有听过不要重复造轮子?因为有些开源的工具,它们经过时间和众人的捶打,其实会比我们自己一个人造出来的轮子考虑的更加周到和全面。可是有时候有些开源工具...

21270
来自专栏大内老A

WCF技术剖析之二十一:WCF基本异常处理模式[中篇]

通过WCF基本的异常处理模式[上篇], 我们知道了:在默认的情况下,服务端在执行某个服务操作时抛出的异常(在这里指非FaultException异常),其相关的...

207100
来自专栏Java后端技术

基于Spring的可扩展Schema进行开发自定义配置标签支持

  最近和朋友一起想开发一个类似alibaba dubbo的功能的工具,其中就用到了基于Spring的可扩展Schema进行开发自定义配置标签支持,通过上网查资...

8830
来自专栏飞雪无情的博客

Go语言实战笔记(十七)| Go 读写锁

前面的有篇文章在讲资源竞争的时候,讲互斥锁,互斥锁的根本就是当一个goroutine访问的时候,其他goroutine都不能访问,这样肯定保证了资源的同步,避免...

7120
来自专栏编程

看我是如何把SQLMap里的功能移植到我的程序的

不知道各位有没有听过不要重复造轮子?因为有些开源的工具,它们经过时间和众人的捶打,其实会比我们自己一个人造出来的轮子考虑的更加周到和全面。可是有时候有些开源工具...

216100
来自专栏梧雨北辰的开发录

iOS面试知识总结之基本概念总结

凡经历过iOS面试的我们总会发觉,即使实际开发中做过许多项目,也难免为一个普通的面试题受挫。这也许不是因为我们技术不过关,而是因为在平时我们忽略了怎样将用到的知...

41970
来自专栏智能大石头

STM32/GD32上内存堆栈溢出探测研究

无数次遭受堆栈溢出折磨,随着系统变得复杂,故障点越来越难以查找! 主要溢出情况如下: 1,一般RAM最后两块空间是堆Heap和栈Stack,堆从下往上用,栈从上...

26570
来自专栏码云1024

MFC多线程

49660
来自专栏逸鹏说道

Python3 与 C# 扩展之~装饰器专栏

终于期末考试结束了,聪明的小明同学现在当然是美滋滋的过暑假了,左手一只瓜,右手一本书~正在给老乡小张同学拓展他研究多日的知识点

20840
来自专栏java达人

基于Spring可扩展Schema提供自定义配置支持(spring配置文件中 配置标签支持)

原文链接:http://www.cnblogs.com/jifeng/archive/2011/09/14/2176599.html (点击阅读原文前往)

13920

扫码关注云+社区

领取腾讯云代金券