• 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html
  • 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html

Spring 的自定义Schema是如何解析生效的

技术杂谈 勤劳的小蚂蚁 4个月前 (12-30) 69次浏览 已收录 0个评论 扫描二维码

随着 Spring Boot 的日渐流行,应用里的大部分配置都被隐藏了起来,我们仅需要关心真正的业务内容, Controller, Service, Repository,拿起键盘就是一通业务代码的Coding,具体的 Component Scan,View,PlaceHolder … 都可以抛在脑后。但其实这种零配置在 Java 应用开发中,还真不太久。 「由奢入俭难」,不少开发者都经历过 Spring XML 配置的冗长,再回到这种配置确实不好受。

但有些时候,由于配置的内容在 Spring Boot这种零配置中并不能很好的实现,就需要我们仍使用 XML 的配置形式,然后再 ImportSource进来。或者一些项目受环境等影响,未使用Boot进行开发,此时也需要对配置有一定的了解。

那这次让我们往回看一些,看看在 XML 配置中,一些自定义的 Schema 内容,是如何融合到 Spring 中进行配置的。例如:


Spring data es

dubbo

还有许多这样的例子,我们不再一一罗列。但通过上述两个图,我们发现一个共同的特点:

  • 都是通过schemaLocation将对应的schema引入
  • 在对应的beans元素中增加更具体的自定义配置

那这些自定义的配置,是在什么时候工作的呢?如何校验是否配置正确?

我们来看 Spring 中包含一个名为 spring.handlers的文件,所有的自定义扩展,都是通过这个文件生效的。spring 官方的aop, tx 也都是这个原理。
这个文件在哪呢?
如上图所示,是META-INF/spring.handlers。文件内容也超级简单:


前面是各个schema前缀,后面是schema 对应的解析类。这个spring.handlers文件是什么时候加载的呢?

这个也是发生在解析自定义配置文件过程中,有一个resolve的过程,此时会将当前classLoader对应的所有包含spring.handlers文件加载过来。

我们再来看这个解析类,内容如下:

1public class ElasticsearchNamespaceHandler extends NamespaceHandlerSupport {
2    public ElasticsearchNamespaceHandler() {
3    }
4
5    public void init() {
6        RepositoryConfigurationExtension extension = new ElasticsearchRepositoryConfigExtension();
7        RepositoryBeanDefinitionParser parser = new RepositoryBeanDefinitionParser(extension);
8        this.registerBeanDefinitionParser(“repositories”, parser);
9        this.registerBeanDefinitionParser(“node-client”new NodeClientBeanDefinitionParser());
10        this.registerBeanDefinitionParser(“transport-client”new TransportClientBeanDefinitionParser());
11    }
12}

首先是继承自NamesapceHandlerSupport
然后在重写的init方法中注册了一系列的parser,每个parser对应一个字符串,就是我们在xml配置文件是使用的自定义内容,比如上面的es的配置

<elasticsearch:transport-client id=”client”
  cluster-nodes=”192.168.73.186:9300″ cluster-name=”elasticsearch” />

这里的配置最终就会通过 TransportClientBeanDefinitionParser  来进行解析
而上面提到的各个parser,在init方法中,保存在了一个Map中

private final Map<String, BeanDefinitionParser> parsers = new HashMap();

所谓注册parser,就是在向这个parsers的map进行put操作。

那回过头来,在Spring中,最核心的内容是什么呢? 是Bean。而实际上我们配置到XML里的这些内容,最终也会生在一个对应的Bean,所有的配置,只是为了生成Bean,这些自定义的配置,都称之为BeanDefinition。
所以,Spring 在解析配置文件是,会有如下的判断,是否是defaultNamespace,不是的话就走customElementParse

1protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
2        if(delegate.isDefaultNamespace(root)) {
3            NodeList nl = root.getChildNodes();
4
5            for(int i = 0; i < nl.getLength(); ++i) {
6                Node node = nl.item(i);
7                if(node instanceof Element) {
8                    Element ele = (Element)node;
9                    if(delegate.isDefaultNamespace(ele)) {
10                        this.parseDefaultElement(ele, delegate);
11                    } else {
12                        delegate.parseCustomElement(ele);
13                    }
14                }
15            }
16        } else {
17            delegate.parseCustomElement(root);
18        }
19
20    }

而是不是defaultNameSpace的判断更直接:namespace的uri有没有内容,或者是不是spring 的beans的声明
1public boolean isDefaultNamespace(String namespaceUri) {
2        return !StringUtils.hasLength(namespaceUri) || http://www.springframework.org/schema/beans&#8221;.equals(namespaceUri);
3    }

所以请求都走到了parseCustomElement里,这里开始进行配置的解析, parse的时候,通过uriResolver查到对应的Handler

1public BeanDefinition parseCustomElement(Element ele, BeanDefinition containingBd) {
2        String namespaceUri = this.getNamespaceURI(ele);
3        NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
4        if(handler == null) {
5            this.error(“Unable to locate Spring NamespaceHandler for XML schema namespace [“ + namespaceUri + “]”, ele);
6            return null;
7        } else {
8            return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
9        }
10    }


那此时返回的仅仅是spring.handlers里配置的Handler,而每个Handler又注册了不少的parse,还得需要一个获取parser的过程

1public BeanDefinition parse(Element element, ParserContext parserContext) {
2        return this.findParserForElement(element, parserContext).parse(element, parserContext);
3 }
4
5    private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) {
6        String localName = parserContext.getDelegate().getLocalName(element);
7        BeanDefinitionParser parser = (BeanDefinitionParser)this.parsers.get(localName);
8        if(parser == null) {
9            parserContext.getReaderContext().fatal(“Cannot locate BeanDefinitionParser for element [“ + localName + “]”, element);
10        }
11
12        return parser;
13 }

这个获取的过程,就是通过传入的string,在我们开始声明的Map里 get对应的parser,再使用它进行配置的解析啦。

有了parser,后面就是生成BeanDefinition的过程。
我们看,这些parser,都是继承自AbstraceBeanDefinitionParser,或者实现了BeanDefinitionParser 的接口,统一解析的入口处,是接口的parse方法。
1public class TransportClientBeanDefinitionParser extends AbstractBeanDefinitionParser {
2    public TransportClientBeanDefinitionParser() {
3    }
4
5    protected AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) {
6        BeanDefinitionBuilder builder = BeanDefinitionBuilder.rootBeanDefinition(TransportClientFactoryBean.class);
7        this.setConfigurations(element, builder);
8        return this.getSourcedBeanDefinition(builder, element, parserContext);
9    }
10}

在重写的parseInternal方法中,返回解析配置后对应的BeanDefinition。这里也是各个框架自由抽象的地方。比如有些框架是简单直接一个类,而有些在此处会应用一些类似策略、装饰器等设计模式,提供更多的灵活性

具体获取到BeanDefinition之后,放到整个Context中如何生成 Spring Bean的内容,以后我们再做分析。

丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:Spring 的自定义Schema是如何解析生效的
喜欢 (0)
[247507792@qq.com]
分享 (0)
勤劳的小蚂蚁
关于作者:
温馨提示:本文来源于网络,转载文章皆标明了出处,如果您发现侵权文章,请及时向站长反馈删除。

您必须 登录 才能发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00