Spring自定义标签体系和应用

我们知道，在使用Dubbo框架时，需要指定配置文件中的application、protocol、registry、provider、service等服务器端和客户端的配置项，典型的配置方法如下所示。通过这些配置项，我们可以基于Spring容器来启动Dubbo服务。

<!-- 提供方应用信息，用于计算依赖关系 -->  

<dubbo:application name="demo-provider"/>  

<!-- 用dubbo协议在20880端口暴露服务 -->  

<dubbo:protocol name="dubbo" port="20880"/>  

<!-- 使用zookeeper注册中心暴露服务地址 -->  

<dubbo:registry address="zookeeper://127.0.0.1:2181" id="registry"/>  

<!-- 默认的服务端配置 -->  

<dubbo:provider registry="registry" retries="0" timeout="5000"/>  

<!-- 和本地bean一样实现服务 -->  

<bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl"/>  

<!-- 声明需要暴露的服务接口 -->  

<dubbo:service interface="org.apache.dubbo.demo.DemoServicee" ref="demoService"/>

看到这些配置项，你可能会好奇，因为它们都不是Spring内置的配置项，而是Dubbo框架所特有的。那么，Spring是如何识别和使用这些配置项的呢？这就是今天要介绍的内容，即Spring所具备的自定义标签体系及其应用方式。

什么Spring自定义标签体系？

在介绍Spring的自定义标签体系之前，我们先来回顾一下AbstractApplicationContext中的refresh方法，其中存在如下所示的一行关键代码。

public void refresh() throws BeansException, IllegalStateException {

…

//获取Beanfactory

ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

…

}

上述语句会刷新BeanFactory，加载XML配置文件从而生成Map<String,BeanDefinition>的一个映射。这个加载Bean的场景是一个比较常见的扩展点时机。

我们知道在Spring的XML中配置如下所示的bean的定义，Spring就会在容器启动时进行解析然后转换成特定的BeanDefinition。

<bean id="myClass" class="com.demo.MyClass"/>

显然，对于扩展性而言，我们完全可以在这种Bean定义中添加自己所需的任何标签，从而实现定制化控制功能。Spring允许你自己定义XML结构并且可以用自己的Bean解析器进行解析。从扩展性的角度讲，基于配置文件的扩展也是非常常见和实用的扩展方法。通过这种实现技术，我们自己开发的框架也可以和Spring完成无缝的集成。

Spring自定义标签体系的开发流程

想要做到基于标签的扩展机制，Spring也提供了一套固定的开发流程，主要包括四个步骤。

接下来，让我们对上图中的开发步骤一一进行展开。

编写扩展对象和XSD文件

首先，我们可以根据需要设计一个业务对象，例如如下所示的Account对象。

public class Account{

 private String id;

 private String name;

 private Integer age;

}

如果我们希望该对象中的所有字段都能够进行配置，那么就可以针对这些配置项编写XSD文件，XSD是XML Schema的定义文件，本例中的XSD文件如下所示。

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema

xmlns="http://spring.xiaoyiran.com/dailyclass/schema/account"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:beans="http://www.springframework.org/schema/beans"

targetNamespace=" http://spring.xiaoyiran.com/dailyclass/schema/account "

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xsd:import namespace="http://www.springframework.org/schema/beans" />

<xsd:element name="account">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="beans:identifiedType">

<xsd:attribute name="name" type="xsd:string" />

<xsd:attribute name="age" type="xsd:int" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

</xsd:schema>

上述定义中，我们针对Account对象的三个字段做了定义。这里使用的定义方法都是XSD中的固定用法。请注意，我们这里就通过targetNamespace配置项指定了Account对象所属的命名空间。

XSD文件完成后需要存放在classpath下，一般都放在META-INF目录下。

编写NamespaceHandler实现类

想要完成对上述配置项的解析工作，需要用到NamespaceHandler和BeanDefinitionParser这两个核心类。其中NamespaceHandler会根据Schema和节点名找到某个BeanDefinitionParser，然后由BeanDefinitionParser完成具体的解析工作。通过这两个类之间协作过程，我们将完成从XSD到Spring中BeanDefinition的转换过程。

想要从零开始实现一个NamespaceHandler还是有比较复杂的，通常也没有必要。幸好Spring已经为我们提供了默认的NamespaceHandlerSupport实现类。实际上，Spring内部很多特定组件的配置项解析也依赖于在这个NamespaceHandlerSupport类的基础之上演变出各种子类。所以，如果我们想要实现一个自定的NamespaceHandler，最简单的方法就是继承NamespaceHandlerSupport然后在它的init方法中执行如下所示的registerBeanDefinitionParser方法。

public class AccountNamespaceHandler extends NamespaceHandlerSupport {

    public void init() {

        registerBeanDefinitionParser("account", new AccountBeanDefinitionParser());

    }

}

可以看到，这里出现了一个AccountBeanDefinitionParser。通过以上方法，当我们在Spring的在配置中引用<account>配置项时，就会用AccountBeanDefinitionParser来解析配置。让我们一起来看一下。

编写BeanDefinitionParser实现类

上述AccountBeanDefinitionParser就是一个BeanDefinitionParser接口的实现类，该接口专门用来将配置项转换为BeanDefinition。

针对这一接口，Spring同样为我们提供了它的一个抽象实现类AbstractBeanDefinitionParser。请注意，AbstractBeanDefinitionParser类是一个典型的模板类，这点从它的parse方法的主流程就可以看出。

public final BeanDefinition parse(Element element, ParserContext parserContext) {

AbstractBeanDefinition definition = parseInternal(element, parserContext);

if (definition != null && !parserContext.isNested()) {

try {

String id = resolveId(element, definition, parserContext);

String[] aliases = new String[0];

String name = element.getAttribute(NAME_ATTRIBUTE);

BeanDefinitionHolder holder = new BeanDefinitionHolder(definition, id, aliases);

registerBeanDefinition(holder, parserContext.getRegistry());

}

}

return definition;

}

这段代码完成了BeanDefinition从解析到注册的主流程。这里第一句parseInternal是AbstractBeanDefinitionParser类提供的抽象方法，需要子类进行实现。一方面，我们可以直接继承AbstractBeanDefinitionParser以实现这个子类（例如后面要介绍Dubbo就是采用这种实现方法），而在Spring中也抽象了几个AbstractBeanDefinitionParser的实现类以降低二次扩展的难度，其中最典型的就是AbstractSingleBeanDefinitionParser类。我们找到这个类发现它同样也是一个模板类。在AbstractSingleBeanDefinitionParser的parseInternal方法的代码结构如下所示。

protected final AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) {

//创建BeanDefinitionBuilder

BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition();

…

  //抽象方法，交由子类实现具体的转换过程

doParse(element, parserContext, builder);

  //返回BeanDefinitionBuilder所构建的BeanDefinition

return builder.getBeanDefinition();

}

显然，这里再次调用了doParse这个抽象方法。请注意这里的BeanDefinitionBuilder，作为BeanDefinition的构造器组件，它同样传递给了doParse方法。

按照Spring中一般的方法命名风格，doParse应该是整个方法调用链的末端方法，也是我们自定义BeanDefinitionParser所需要实现的方法。因此，针对上述示例，我们可以实现如下所示的继承了AbstractSingleBeanDefinitionParser的AccountBeanDefinitionParser类。

public class AccountBeanDefinitionParser extends AbstractSingleBeanDefinitionParser {

    protected Class getBeanClass(Element element) {

        return Account.class;

    }

    protected void doParse(Element element, BeanDefinitionBuilder bean) {

        String name = element.getAttribute("name");

        String age = element.getAttribute("age");

        String id = element.getAttribute("id");

        if (StringUtils.hasText(id)) {

            bean.addPropertyValue("id", id);

        }

        if (StringUtils.hasText(name)) {

            bean.addPropertyValue("name", name);

        }

        if (StringUtils.hasText(age)) {

            bean.addPropertyValue("age", Integer.valueOf(age));

        }

    }

}

这里的核心还是使用BeanDefinitionBuilder添加了各种自定义的配置项。

编写spring.handlers和spring.schemas

实现自定义标签的最后一步是编写spring.handlers和spring.schemas这两个配置文件，这两个文件需要我们自己编写并放入META-INF文件夹中。请注意，这两个文件的地址必须是当前代码工程下的META-INF/spring.handlers和META-INF/spring.schemas。其中，spring.schemas配置文件用来指定XSD文件的路径，XSD文件文件中包含了命名空间的定义。而spring.handlers则用来把命名空间和NamespaceHandler对应起来。

至此，整个基于Spring自定义标签体系的开发流程介绍完毕。接下里，就让我们来看一下Dubbo中如何这套体系实现与Spring框架之间的集成。

解析Dubbo中的自定义标签体系

让我们回顾Dubbo启动方法。我们在今天内容的开头已经提到Dubbo配置项中提供的application、protocol、registry、provider、service等服务器端和客户端的配置项，Dubbo提供了一套解析方法和过程来完成配置项到具体实现类的转变过程。

事实上，Dubbo提供了专门的DubboNamespaceHandler来完成各个配置项的解析，如下所示。

public class DubboNamespaceHandler extends NamespaceHandlerSupport {

    public void init() {

        registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true));

        …

    }

}

可以看到这个DubboNamespaceHandler就直接继承了Spring提供的NamespaceHandlerSupport类，然后针对各个配置项通过registerBeanDefinitionParser方法注册了各自对应的BeanDefinitionParser，Dubbo中这个BeanDefinitionParser就是DubboBeanDefinitionParser。这些类之间关联关系如下图所示。

然后我们来看DubboBeanDefinitionParser中parse方法的代码结构，这个方法比较长，给出它的整体流程。

在上述流程中，Dubbo会分别对一些特定的Bean定义做了特殊处理，包括ProtocolConfig、ServiceBean、ProviderConfig、ConsumerConfig等，分别考虑这些Bean中存在的子节点、ref引用等配置项，我们结合Dubbo配置项示例不难理解这些代码的处理逻辑。而这部分工作涉及到大量对Dubbo中配置属性的解析过程。这些解析过程最终都是使用以下语句完成了对Spring的BeanDefinition的填充。

BeanDefinition.getPropertyValues().addPropertyValue(property, value)

总体而言，DubboBeanDefinitionParser的实现复杂度来自于Dubbo中配置项的复杂度。对于我们日常开发中所需要实现的BeanDefinitionParse组件的开发模式而言，本质上没有什么特殊之处。Dubbo中的整个自定义配置标签体系完全采用了Spring中基于命名空间进行扩展的标准实现机制。通过这样一个过程，就实现了将XML自定义的标签加载到Spring容器中，而不需要使用Spring自己的Bean去定义。这是日常开发过程中的一种简单而实用的技巧，应用非常广泛。

总结

如果想要基于Spring框架来实现一个自定义标签，从而为系统提供更多的可扩展性，那么今天的内容可以帮助你完整这一目标。事实上，如果我们的目标是开发一个与Spring进行有效集成的自定义框架（例如Dubbo和Mybatis），那么自定义标签可以说是必不可少的一个环节，因为在Spring框架中，我们一般都需要依赖于它的自定义标签体系完成一些配置项的设置和装配工作。