Spring源码深度解析总结（5）—— 配置文件的读取和Bean的加载（三）

上一篇我们将Spring解析默认标签bean的流程了解了一遍，这篇文章我们继续来看一下对于自定义标签bean，Spring又是如何解析的。在开始看代码之前，我们先了解一下自定义标签的使用过程

在很多情况下，我们需要为系统提供可配置化支持，简单的做法可以直接基于Spring的标准bean来配置，但配置较为复杂或者需要更多丰富控制的时候，会显得非常笨拙。一般的做法会用原生态的方式去解析定义好的XML文件，然后转化为配置对象。这种方式当然可以解决所有问题，但实现起来比较繁琐，特别是配置非常复杂的时候，解析工作是一个不得不考虑的负担。Spring提供了可扩展Schema的支持，这是一个不错的折中方案。扩展Spring自定义标签配置大致需要以下几个步骤（前提是要把Spring的Core包加入项目中）

（1）创建一个需要扩展的组件

（2）定义一个XSD文件描述组件内容

（3）创建一个文件，实现BeanDefinitionParse接口，用来解释XSD文件中的定义和组件定义

（4）创建一个Handle文件，扩展字NamespaceHandlerSupport，目的是将组件注册到Spring容器

（5）编写Spring.handlers和Spring.schemas文件

现在我们就按照上面的步骤一步步来体验一下自定义标签的过程

（1）首先我们创建一个普通的POJO，这个POJO没有任何特别之处，只是用来接收配置文件

package test.customtag;

public class User{
	private String userName;
	private String email;
	//此处省略get、set方法
}

（2）定义一个XSD文件描述组件内容

<?xml verison="1.0" encoding="UTF-8">
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.lexueba.com/schema/user"
xmlns:tns="http://www.lexueba.com/schema/user"
elementFormDefault="qualified">

	<element name="user">
		<complexType>
			<attribute name="id" type="string" />
			<attribute name="userName" type="string" />
			<attribute name="email" type="string" />
		</complexType>
	</element>
</schema>

（3）创建一个文件，实现BeanDefinitionParse接口，用来解析XSD文件中的定义和组件定义

package test.customtag;
import org.Springframework.beans.factory.support.BeanDefinitionBuilder;
import org.Springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser;
import org.Springframework.util.StringUtils;
import org.w3c.dom.Element;

public class UserBeanDefinitionParser extends AbstractSingleBeanDefinitionParser{

	//Element对应的类
	protected class getBeanClass(Element element){
		return User.class;
	}

	protected void doParse(Element element, BeanDefinitionBuilder bean){
		String userName = element.getAttribute("userName");
		String email = element.getAttribute("email");
		if(StringUtil.hasText(userName)){
			bean.addPropertyValue("userName", userName);
		}

		if(StringUtil.hasText(email)){
			bean.addPropertyValue("email", email);
		}
	}
}

（4）创建一个Handler文件，扩展字NamespaceHandlerSupport，目的是将组件注册到Spring容器

package test.customtag;
import org.Springframework.beans.factory.xml.NamespaceHandlerSupport;

public class MyNamespaceHandler extends NamespaceHandlerSupport{
	public void init(){
		registerBeanDefinitionParser("user", new UserBeanDefinitionParser());
	}
}

代码很简单，无非是当遇到自定义标签<user:aaa 这样类似于user开头的元素，就会把这个元素扔给对应的UserBeanDefinitionParser去解析。

（5）编写Spring.handlers和Spring.schemas文件，默认位置在工程的/META-INF/文件夹下，当然，你可以通过Spring的扩展或者修改源码的方式改变路径。

Spring.handlers——http\://www.lexueba.com/schema/user=test.customtag.MyNameSpaceHandler

Spring.schemas——http\://www.lexueba.com/schema/user.xsd=META-INF/Spring-test.xsd

到这里，自定义的配置就结束了，而Spring加载自定义的大致流程就是遇到自定义标签然后就去Spring.handlers和Spring.schemas中去找对应的handler和XSD，默认位置是/META-INF/下，进而找到对应的handler和解析元素的Parser，从而完成整个自定义元素的解析，也就是说自定义与Spring默认的标准配置不同在于Spring将自定义标签解析的工作委托给了用户去实现。

（6）创建测试配置文件，在配置文件中引入对应的命名空间以及XSD后，便可以直接使用自定义标签了。

<beans xmlns="http://www.Springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:myname="http://www.lexueba.com/schema/user"
	xsi:schemaLocation="http://www.Springframework.org/schema/beans 
		http://www.Springframework.org/schema/beans/Spring-beans-2.0.xsd"
		http://www.lexueba.com/schema/user
		http://www.lexueba.com/schema/user.xsd>
	<myname:user id="testbean" userName="aaa" email="bbb" />
</beans>

（7）测试

public static void main (String[] args){
	ApplicationContext bf = new ClassPathXmlApplicationContext("test/customtag/test.xml");
	User user = (User)bf.getBean("testbean");
	System.out.println(user.getUserName() + "," + user.getEmail());
}

不出意外的话，应该可以看到控制台打印出了我们期待的结果：aaa，bbb

在上面的例子中，我们实现了通过自定义标签实现了通过属性的方式将user类型的Bean赋值，在Spring中自定义标签非常常用，例如我们熟知的事务标签：tx(<tx:annotation-driven>)

了解自定义标签的使用后，我们带着强烈的好奇心来探究一下自定义标签的解析过程

	public BeanDefinition parseCustomElement(Element ele) {
		return parseCustomElement(ele, null);
	}

	//containingBd为父类bean，对顶层元素的解析应设置为null
	public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
		//获取对应的命名空间
		String namespaceUri = getNamespaceURI(ele);
		if (namespaceUri == null) {
			return null;
		}
		//根据命名空间找到对应的NamespaceHandler
		NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
		if (handler == null) {
			error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
			return null;
		}
		//调用自定义的NamespaceHandler进行解析
		return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
	}

相信了解了自定义标签的使用方法后，或多或少会对自定义标签的实现过程有一个自己的想法。其实思路非常简单，无非是根据对应的bean获取对应的命名空间，根据命名空间解析对应的处理器，然后根据用户自定义的处理器进行解析。可是有些事说来简单做起来难，我们先看看如何获取命名空间吧。

标签的解析是从命名空间的提起开始的，无论是区分Spring中默认标签和自定义标签还是区分自定义标签中不同标签的处理器都是以标签所提供的命名空间为基础的，而至于如何提取对应元素的命名空间其实并不需要我们亲自去实现吗，在org.w3c.dom.Node中已经提供了方法供我们直接调用

public String getNamespaceURI(Node node){
	return node.getNamespaceURI();
}

有了命名空间，就可以进行NamespaceHandler的提取了，继续之前的parseCustomElement函数的跟踪，来分析一下getNamespaceHandlerResolver().resolve()函数，在readerContext初始化的时候其属性namespaceHandlerResolver已经被初始化为了DefaultNamespaceHandlerResolver的实例，所以这里调用的resolve方法其实调用的是DefaultNamespaceHandlerResolver类中的方法。我们进入DefaultNamespaceHandlerResolver的resolve方法看看

	public NamespaceHandler resolve(String namespaceUri) {
		//获取所有已经配置的handler映射
		Map<String, Object> handlerMappings = getHandlerMappings();
		//根据命名空间找到对应的信息
		Object handlerOrClassName = handlerMappings.get(namespaceUri);
		if (handlerOrClassName == null) {
			return null;
		}
		else if (handlerOrClassName instanceof NamespaceHandler) {
			//已经做过解析的情况，直接从缓存读取
			return (NamespaceHandler) handlerOrClassName;
		}
		else {
			//没有做过解析，则返回的是类路径
			String className = (String) handlerOrClassName;
			try {
				//使用反射将类路径转化为类
				Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);
				if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) {
					throw new FatalBeanException("Class [" + className + "] for namespace [" + namespaceUri +
							"] does not implement the [" + NamespaceHandler.class.getName() + "] interface");
				}
				//初始化类
				NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);
				//调用自定义的NamespaceHandler的初始化方法
				namespaceHandler.init();
				//记录在缓存
				handlerMappings.put(namespaceUri, namespaceHandler);
				return namespaceHandler;
			}
			catch (ClassNotFoundException ex) {
				throw new FatalBeanException("Could not find NamespaceHandler class [" + className +
						"] for namespace [" + namespaceUri + "]", ex);
			}
			catch (LinkageError err) {
				throw new FatalBeanException("Unresolvable class definition for NamespaceHandler class [" +
						className + "] for namespace [" + namespaceUri + "]", err);
			}
		}
	}

上面的函数清晰的阐述了解析自定义NamespaceHandler的过程，通过之前的示例程序我们了解到如果要使用自定义标签，那么其中一项必不可少的操作就是在Spring.handlers文件中配置命名空间与命名空间处理器的映射关系。只有这样，Spring才能根据映射关系找到匹配的处理器，而寻找匹配的处理器就是在上面函数中实现的，当获取自定义的NamespaceHandler之后就可以进行处理器初始化并解析了。我们不妨再次回忆一下示例中对于命名空间处理器的内容

public class MyNamespaceHandler extends NamespaceHandlerSupport{
	public void init(){
		registerBeanDefinitionParser("user", new UserBeanDefinitionParser());
	}
}

当得到自定义命名空间处理后会马上执行namespaceHandler.init()来进行自定义BeanDefinitionParser的注册。在这里，你可以注册多个标签解析器，当前示例中只有支持<myname:user的写法，你也可以在这里注册多个解析器，如<myname:a、<myname:b等，使得myname的命名空间可以支持多种标签解析。

注册后，命名空间处理器就可以根据标签的不同来调用不同的解析器进行解析。那么根据上面的函数与之前介绍过的例子，我们基本可以推断getHandlerMappings的主要功能就是读取Spring.Handlers配置文件并将配置文件缓存到map中。

	private Map<String, Object> getHandlerMappings() {
		Map<String, Object> handlerMappings = this.handlerMappings;
		//如果没有缓存则开始进行缓存
		if (handlerMappings == null) {
			synchronized (this) {
				handlerMappings = this.handlerMappings;
				if (handlerMappings == null) {
					try {
						//this.handlerMappingsLocation 在构造函数中已经被初始化为：META-INF/Spring.handlers
						Properties mappings =
								PropertiesLoaderUtils.loadAllProperties(this.handlerMappingsLocation, this.classLoader);
						if (logger.isDebugEnabled()) {
							logger.debug("Loaded NamespaceHandler mappings: " + mappings);
						}
						Map<String, Object> mappingsToUse = new ConcurrentHashMap<>(mappings.size());
						//将Properties格式文件合并到Map格式的handlerMappings中
						CollectionUtils.mergePropertiesIntoMap(mappings, mappingsToUse);
						handlerMappings = mappingsToUse;
						this.handlerMappings = handlerMappings;
					}
					catch (IOException ex) {
						throw new IllegalStateException(
								"Unable to load NamespaceHandler mappings from location [" + this.handlerMappingsLocation + "]", ex);
					}
				}
			}
		}
		return handlerMappings;
	}

同我们想像的一样，借助了工具类PropertiesLoaderUtils对属性handlerMappingLocation进行了配置文件的读取，handlerMappingLocation被默认初始化为"META-INF/Spring.handlers"

得到了解析器以及要分析的元素后，Spring就可以将解析工作委托给自定义解析器去解析了。以之前提到的示例进行分析，此时的handler已经被实例化成为了我们自定义的MyNamespaceHandler了，而MyNamespaceHandler也完成了初始化的工作，但是在我们实现的自定义命名空间处理器中并没有实现parse方法，所以推断，这个方法是继承自父类NamespaceHandlerSupport中的parse方法

	public BeanDefinition parse(Element element, ParserContext parserContext) {
		//寻找解析器并进行解析操作
		BeanDefinitionParser parser = findParserForElement(element, parserContext);
		return (parser != null ? parser.parse(element, parserContext) : null);
	}

解析过程首先是寻找元素对应的解析器，进而调用解析器中的parse方法，那么结合示例来讲，其实就是首先获取在MyNamespaceHandler类中的init方法中注册的对应的UserBeanDefinitionParser实例，并调用其parse方法进一步解析。

	private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) {
		//获取元素名称，也就是<myname:user中的user，若在示例中，此时的localName为user
		String localName = parserContext.getDelegate().getLocalName(element);
		BeanDefinitionParser parser = this.parsers.get(localName);
		//根据user找到对应的解析器，也就是在registerBeanDefinitionParser("user",new UserBEANDefinitionParser());注册的解析器
		if (parser == null) {
			parserContext.getReaderContext().fatal(
					"Cannot locate BeanDefinitionParser for element [" + localName + "]", element);
		}
		return parser;
	}

而对于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);
				if (!StringUtils.hasText(id)) {
					parserContext.getReaderContext().error(
							"Id is required for element '" + parserContext.getDelegate().getLocalName(element)
									+ "' when used as a top-level tag", element);
				}
				String[] aliases = null;
				if (shouldParseNameAsAliases()) {
					String name = element.getAttribute(NAME_ATTRIBUTE);
					if (StringUtils.hasLength(name)) {
						aliases = StringUtils.trimArrayElements(StringUtils.commaDelimitedListToStringArray(name));
					}
				}
				BeanDefinitionHolder holder = new BeanDefinitionHolder(definition, id, aliases);
				registerBeanDefinition(holder, parserContext.getRegistry());
				if (shouldFireEvents()) {
					BeanComponentDefinition componentDefinition = new BeanComponentDefinition(holder);
					postProcessComponentDefinition(componentDefinition);
					parserContext.registerComponent(componentDefinition);
				}
			}
			catch (BeanDefinitionStoreException ex) {
				String msg = ex.getMessage();
				parserContext.getReaderContext().error((msg != null ? msg : ex.toString()), element);
				return null;
			}
		}
		return definition;
	}

虽说是对自定义配置文件的解析，但是，我们可以看到，在这个函数中大部分的代码是用来处理将解析后的AbstractBeanDefinition转化为BeanDefinitionHolder并注册的功能，而真正去做解析的事情委托给了parseInternal，正是这句代码调用了我们自定义的解析函数。

在parseInternal中并不是直接调用自定义的doParse函数，而是进行了一系列的数据准备，包括对beanClass、scope、lazyInit等属性的准备。

	protected final AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) {
		BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition();
		String parentName = getParentName(element);
		if (parentName != null) {
			builder.getRawBeanDefinition().setParentName(parentName);
		}
		//获取自定义标签中的class，此时会调用自定义解析器如UserBeanDefinitionParser中的getBeanClass方法
		Class<?> beanClass = getBeanClass(element);
		if (beanClass != null) {
			builder.getRawBeanDefinition().setBeanClass(beanClass);
		}
		else {
			//若子类没有重写getBeanClass方法则尝试检查子类是否重写getBeanClassName方法
			String beanClassName = getBeanClassName(element);
			if (beanClassName != null) {
				builder.getRawBeanDefinition().setBeanClassName(beanClassName);
			}
		}
		builder.getRawBeanDefinition().setSource(parserContext.extractSource(element));
		BeanDefinition containingBd = parserContext.getContainingBeanDefinition();
		if (containingBd != null) {
			//若存在父类则使用父类的scope属性
			builder.setScope(containingBd.getScope());
		}
		if (parserContext.isDefaultLazyInit()) {
			//配置延迟加载
			builder.setLazyInit(true);
		}
		//调用子类重写的doParse方法进行解析
		doParse(element, parserContext, builder);
		return builder.getBeanDefinition();
	}

回顾一下全部的自定义标签处理过程，虽然在实例中我们定义UserBeanDefinitionParser，但是在其中我们只是做了与自己业务逻辑相关的部分。不过我们没做不代表没有，在这个处理过程中同样是按照Spring中默认标签的处理方式进行，包括创建BeanDefinition以及进行相应默认属性的设置，对于这些工作Spring都默默的帮我们实现了，只是暴露出了一些接口来提供给用户实现个性化的业务。

至此，Spring对于配置文件的解析我们就全部分析完了，下一篇我们将开始分析Spring对于Bean的加载的流程是实现代码。