全网最深分析SpringBoot MVC自动配置失效的原因

 更新时间:2020年07月01日 10:48:01   作者:夜勿语  
这篇文章主要介绍了全网最深分析SpringBoot MVC自动配置失效的原因,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

前言

本来没有计划这一篇文章的,只是在看完SpringBoot核心原理后,突然想到之前开发中遇到的MVC自动失效的问题,虽然网上有很多文章以及官方文档都说明了原因,但还是想亲自看一看,本以为很简单的事情,没想到却引发出一个较复杂的问题,请教了很多人都没有得到结果,网上文章也没有写清楚的,最后还是自己搞了很久才弄明白的,此篇主要记录自己的一个分析过程。

正文

引出问题


上面是SpringBoot MVC的自动配置,问题是这样的,当我们需要自己配置MVC时,有三种选择:

  • 实现WebMvcConfigurer接口
  • 继承WebMvcConfigurerAdapter类
  • 继承WebMvcConfigurationSupport类

在老版本中我们常用的做法就是继承WebMvcConfigurerAdapter类,这个类本身是实现了WebMvcConfigurer接口的,因为老版本JDK接口没有默认方法,直接实现WebMvcConfigurer比较繁琐,而后来接口可以有默认方法了,WebMvcConfigurerAdapter就被标记为过时了,所以我们现在配置MVC只需要实现WebMvcConfigurer接口或者继承WebMvcConfigurationSupport,但是后者会导致SpringBoot的配置失效,因为在自动配置类上有@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)这样一个注解,表示没有WebMvcConfigurationSupport类及其子类的实例时才会加载自动配置(另外使用@EnableWebMvc注解也会导致自动配置失效)。

MVC自动配置失效的原因就是这个了,基本上所有网上的文章分析到这一步也就完了,但是注意上图我画的红方框,在这个自动配置类中有两个静态内部类,我们知道静态内部类是优于外部类加载的(SpringBoot自动配置大量使用了此特性),而其中EnableWebMvcConfiguration这个类,我注意到它是继承自DelegatingWebMvcConfiguration,而DelegatingWebMvcConfiguration又继承自WebMvcConfigurationSupport类,相信看到这你也应该会有疑惑了,为什么这个配置类没有导致自动配置失效,而我们自己实现的就会?

分析过程

我知道配置类的解析注册是在ConfigurationClassPostProcessor类中,而这个类我前面的文章多次分析过,虽然这个类的实现流程不难,但细节非常绕,所以之前没有深挖。遇到这个问题时,我首先想的是对这个类的理解不够深刻,因此第一时间想到仔细研究这个类,在花费了大量时间断点分析后,却没有太大的收获。

接着我又想,是不是配置类的注册顺序在自动配置的后面。这里我就犯了一个显而易见的错误,因为我考虑的是注册的顺序,不是实例化。因为ConditionalOnMissingBean注解是没有指定bean的实例时才会去加载,而我脑海里当时想成了ConditionalOnMissingClass。所以我在DefaultListableBeanFactory中的registerBeanDefinition和preInstantiateSingletons方法上打上了断点,力图确认注册顺序如我所想:

public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
			throws BeanDefinitionStoreException {

		BeanDefinition existingDefinition = this.beanDefinitionMap.get(beanName);
		if (existingDefinition != null) {
			....
			this.beanDefinitionMap.put(beanName, beanDefinition);
		}
		else {
			if (hasBeanCreationStarted()) {
				// Cannot modify startup-time collection elements anymore (for stable iteration)
				synchronized (this.beanDefinitionMap) {
					this.beanDefinitionMap.put(beanName, beanDefinition);
					List<String> updatedDefinitions = new ArrayList<>(this.beanDefinitionNames.size() + 1);
					updatedDefinitions.addAll(this.beanDefinitionNames);
					updatedDefinitions.add(beanName);
					this.beanDefinitionNames = updatedDefinitions;
					removeManualSingletonName(beanName);
				}
			}
			else {
				// Still in startup registration phase
				this.beanDefinitionMap.put(beanName, beanDefinition);
				this.beanDefinitionNames.add(beanName);
				removeManualSingletonName(beanName);
			}
			this.frozenBeanDefinitionNames = null;
		}
	}

	public void preInstantiateSingletons() throws BeansException {
		List<String> beanNames = new ArrayList<>(this.beanDefinitionNames);
		....
	}


但结果beanDefinitionNames中的顺序却是两个静态内部类在前,也就是说静态内部类肯定是在外部类之前就注册到IOC容器中了,这下我就傻了。但幸好也是因此,否则我就该认为这就是结果了。最终我想到了应该看类的实例化顺序,但是正常情况下类的实例化顺序就是上面的断点图中的顺序,我想会不会是有什么类依赖了WebMvcAutoConfiguration,导致它提前实例化。于是我将断点又设置到AbstractBeanFactory中的doGetBean方法并加上了条件(不得不说idea的功能非常强大,回到上一个调用点、给断点设置条件、调用堆栈信息大大节省了我的调试时间):


然后启动项目就可以看到首先实例化的果然是WebMvcAutoConfiguration类,这样就搞清楚了为什么EnableWebMvcConfiguration没有导致自动配置失效。

但是还没完,为什么自动配置类会在静态内部类之前实例化呢?是由谁触发的呢?继续深入,这时我想到了看调用栈:

粗略看一下调用栈信息,如果对Spring源码熟悉,可以发现自动配置类的实例化是在instantiateUsingFactoryMethod中触发的:

String factoryBeanName = mbd.getFactoryBeanName();
		if (factoryBeanName != null) {
			if (factoryBeanName.equals(beanName)) {
				throw new BeanDefinitionStoreException(mbd.getResourceDescription(), beanName,
						"factory-bean reference points back to the same bean definition");
			}
			factoryBean = this.beanFactory.getBean(factoryBeanName);
			if (mbd.isSingleton() && this.beanFactory.containsSingleton(beanName)) {
				throw new ImplicitlyAppearedSingletonException();
			}
			factoryClass = factoryBean.getClass();
			isStatic = false;
		}
		else {
			// It's a static factory method on the bean class.
			if (!mbd.hasBeanClass()) {
				throw new BeanDefinitionStoreException(mbd.getResourceDescription(), beanName,
						"bean definition declares neither a bean class nor a factory-bean reference");
			}
			factoryBean = null;
			factoryClass = mbd.getBeanClass();
			isStatic = true;
		}

这段代码在bean实例化的那一篇分析过,这个方法的作用是通过factoryMethod实例化当前的BeanDefinition,而实例化该BD优先会实例化factoryBeanName属性指向的Bean,这里的factoryBeanName就是org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration,factoryMethod则是formContentFilter,而这两个属性的设置则是在ConfigurationClassPostProcessor解析@Configuration和@Bean就设置好了(@Bean标注的方法名会设置到factoryMethod,而该方法所在配置类的名称就是factoryBeanName),这里就不展开分析了。

@Configuration(proxyBeanMethods = false)
@ConditionalOnWebApplication(type = Type.SERVLET)
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration.class, TaskExecutionAutoConfiguration.class,
		ValidationAutoConfiguration.class })
public class WebMvcAutoConfiguration {

	public static final String DEFAULT_PREFIX = "";

	public static final String DEFAULT_SUFFIX = "";

	private static final String[] SERVLET_LOCATIONS = { "/" };

	@Bean
	@ConditionalOnMissingBean(HiddenHttpMethodFilter.class)
	@ConditionalOnProperty(prefix = "spring.mvc.hiddenmethod.filter", name = "enabled", matchIfMissing = false)
	public OrderedHiddenHttpMethodFilter hiddenHttpMethodFilter() {
		return new OrderedHiddenHttpMethodFilter();
	}

	@Bean
	@ConditionalOnMissingBean(FormContentFilter.class)
	@ConditionalOnProperty(prefix = "spring.mvc.formcontent.filter", name = "enabled", matchIfMissing = true)
	public OrderedFormContentFilter formContentFilter() {
		return new OrderedFormContentFilter();
	}
	
	......
}

formContentFilter就是在MVC自动配置类中配置的,默认是加载的,而filter就不用多说了,在Tomcat启动后就会触发初始化,追踪调用栈也可以看到。另外我们还看到自动配置类中还配置了一个HiddenHttpMethodFilter,不过这个默认是不加载的,所以我们只要在application.properties中配置了如下属性,自动配置类就不会实例化了,但是两个静态内部类的实例化还是不会受影响的。

spring.mvc.formcontent.filter.enabled=false

总结

该问题只是出于兴趣研究,虽然耗费了大量的时间和精力,但收获不少,加深了对Spring源码的理解,也修正了之前的一些错误理解,另外对于源码更多的是要自己去研究,不能只看一两篇文章或听别人说,只有自己亲手调试过才能知道自己的理解是否正确。

到此这篇关于全网最深分析SpringBoot MVC自动配置失效的原因的文章就介绍到这了,更多相关SpringBoot MVC自动配置失效内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:

相关文章

  • SpringBoot中的健康检查详解

    SpringBoot中的健康检查详解

    这篇文章主要介绍了SpringBoot中的健康检查详解,健康检查是一种用来确保应用程序和其所依赖的服务的状态正常的机制,在本文中,我们将探讨SpringBoot中的健康检查是什么以及如何使用它来监视应用程序的状态,需要的朋友可以参考下
    2023-07-07
  • java中深复制知识点详解

    java中深复制知识点详解

    在本篇文章里小编给大家整理了关于java中深复制知识点详解内容,有需要的朋友们可以学习下。
    2020-12-12
  • SpringBoot使用JPA实现查询部分字段

    SpringBoot使用JPA实现查询部分字段

    这篇文章主要介绍了SpringBoot使用JPA实现查询部分字段方式,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2021-08-08
  • java中年月日的加减法使用示例

    java中年月日的加减法使用示例

    这篇文章主要介绍了java中年月日的加减法使用示例的相关资料,需要的朋友可以参考下
    2023-02-02
  • maven配置阿里云仓库的实现方法(2022年)

    maven配置阿里云仓库的实现方法(2022年)

    本文主要介绍了maven配置阿里云仓库的实现方法,文中通过示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2022-03-03
  • Mybatis之动态SQL使用小结(全网最新)

    Mybatis之动态SQL使用小结(全网最新)

    MyBatis令人喜欢的一大特性就是动态SQL, 在使用JDBC的过程中, 根据条件进行SQL的拼接是很麻烦且很容易出错的,MyBatis通过OGNL来进行动态SQL的使用解决了这个麻烦,对Mybatis动态SQL相关知识感兴趣的朋友跟随小编一起看看吧
    2024-05-05
  • 使用Spring Data JDBC实现DDD聚合的示例代码

    使用Spring Data JDBC实现DDD聚合的示例代码

    这篇文章主要介绍了使用Spring Data JDBC实现DDD聚合的示例代码,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-09-09
  • java Swing实现选项卡功能(JTabbedPane)实例代码

    java Swing实现选项卡功能(JTabbedPane)实例代码

    这篇文章主要介绍了java Swing实现选项卡功能(JTabbedPane)实例代码的相关资料,学习java 基础的朋友可以参考下这个简单示例,需要的朋友可以参考下
    2016-11-11
  • Java程序包不存在的两种解决方法

    Java程序包不存在的两种解决方法

    有时候我们在导入程序之后,系统会给出错误提示:Java:程序包xxxx不存在,本文主要介绍了Java程序包不存在的两种解决方法,具有一定的参考价值,感兴趣的可以了解一下
    2024-02-02
  • Hadoop使用hdfs指令查看hdfs目录的根目录显示被拒的原因及解决方案

    Hadoop使用hdfs指令查看hdfs目录的根目录显示被拒的原因及解决方案

    这篇文章主要介绍了Hadoop使用hdfs指令查看hdfs目录的根目录显示被拒的原因及解决方案,分布式部署hadoop,服务机只有namenode节点,主机包含其他所有节点,本文给大家介绍的非常详细,需要的朋友可以参考下
    2023-10-10

最新评论