全网最深分析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自动配置失效内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • SpringBoot自动配置的实现原理

    一.运行原理 Spring Boot的运行是由注解@EnableAutoConfiguration提供的. @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import({EnableAutoConfigurationImportSelector.class}) public @interface EnableAuto

  • 初识Spring Boot框架之Spring Boot的自动配置

    在上篇博客初识Spring Boot框架中我们初步见识了SpringBoot的方便之处,很多小伙伴可能也会好奇这个spring Boot是怎么实现自动配置的,那么今天我就带小伙伴我们自己来实现一个简单的Spring Boot 自动配置的案例,看看这一切到底是怎么发生的. 假设我的需求是这样的:当我的项目中存在某个类的时候,系统自动为我配置该类的Bean,同时,我这个Bean的属性还可以在application.properties中进行配置,OK,就这样一个需求,我们来看看怎么实现. 1.新建s

  • 全面解析SpringBoot自动配置的实现原理

    之前一直在用SpringBoot框架,一直感觉SpringBoot框架自动配置的功能很强大,但是并没有明白它是怎么实现自动配置的,现在有空研究了一下,大概明白了SpringBoot框架是怎么实现自动配置的功能,我们编写一个最简单的自动配置功能,大概的总结一下. 一,配置属性类 其实就是值对象注入的方式去配置一些Spring常用的配置,我们编写一个最简单的配置对象. @ConfigurationProperties(prefix = "hello") //@Component //如果这

  • Spring Boot 自动配置的实现

    Spring Boot 自动配置 来看下 spring boot中自动配置的注解 @SuppressWarnings("deprecation") @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @AutoConfigurationPackage @Import(EnableAutoConfigurationImportSelector.class) public

  • Spring Boot实战教程之自动配置详解

    前言 大家应该都有所了解,随着Ruby.Groovy等动态语言的流行,相比较之下Java的开发显得格外笨重.繁多的配置.低下的开发效率.复杂的部署流程以及第三方技术集成难度大等问题一直被人们所诟病.随着Spring家族中的新星Spring Boot的诞生,这些问题都在逐渐被解决. 个人觉得Spring Boot中最重要的两个优势就是可以使用starter简化依赖配置和Spring的自动配置.下面这篇文章将给大家详细介绍Spring Boot自动配置的相关内容,话不多说,来一起看看详细的介绍. 使

  • Spring Boot 自动配置之条件注解浅析

    Spring Boot 神奇的自动配置,主要依靠大量的条件注解来使用配置自动化. 根据满足某一个特定条件创建一个特定的Bean.比如说,在某些系统变量下创建Bean,或者只有在某个Bean创建后才去创建另外一个Bean. 就是根据条件来控制Bean的创建行为,可以利用该特性来进行一些自动配置. 一.常用的条件注解 @Conditional 依赖的条件 @ConditionalOnBean  在某个Bean存在的条件下 @ConditionalOnMissingBean 在某个Bean不存在的条件

  • springboot自动配置没有生效的问题定位(条件断点)

    Spring Boot在为开发人员提供更高层次的封装,进而提高开发效率的同时,也为出现问题时如何进行定位带来了一定复杂性与难度.但Spring Boot同时又提供了一些诊断工具来辅助开发与分析,如spring-boot-starter-actuator.本文分享一个基于actuator与IDEA条件断点来定位自动配置未生效的案例.望对类似问题分析与处理提供参考. 问题确认 在前文介绍的 Spring Boot从入门到实战:整合通用Mapper简化单表操作 中,我们对druid连接池做了自动配置,

  • 浅谈springboot自动配置原理

    从main函数说起 一切的开始要从SpringbootApplication注解说起. @SpringBootApplication public class MyBootApplication { public static void main(String[] args) { SpringApplication.run(MyBootApplication.class); } } @SpringBootConfiguration @EnableAutoConfiguration @Compon

  • 通过Spring Boot整合Mybatis分析自动配置详解

    前言 SpringBoot凭借"约定大于配置"的理念,已经成为最流行的web开发框架,所以有必须对其进行深入的了解:本文通过整合Mybatis类来分析SpringBoot提供的自动配置(AutoConfigure)功能,在此之前首先看一个整合Mybatis的实例. SpringBoot整合Mybatis 提供SpringBoot整合Mybatis的实例,通过Mybatis实现简单的增删改查功能: 1.表数据 CREATE TABLE `role` ( `note` varchar(25

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

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

  • Java深入浅出掌握SpringBoot之MVC自动配置原理篇

    Spring Boot 为 Spring MVC 提供了自动配置,适用于大多数应用程序. 官方文档描述: 自动配置在 Spring 的默认值之上添加了以下功能: 从官方描述解析: If you want to keep Spring Boot MVC features and you want to add additionalMVC configuration (interceptors, formatters, view controllers, and other features), y

  • SpringBoot 自动配置失效的解决方法

    目录 问题描述 @EnableConfigurationProperties 注解行为 配置有效,AutoTestConfiguration 未刷新 prefix-type @ConditionalOnProperty @ConditionalOnProperty match 逻辑 @ConditionalOnProperty skip 逻辑 总结 本文源自近期项目中遇到的问题, bug 总是出现在你自以为是的地方... 问题描述 下面是一个简单复现的代码片段,在你没有阅读完本文时,如果能做出正

  • 浅谈什么是SpringBoot异常处理自动配置的原理

    异常处理自动配置 ErrorMvcAutoConfiguration自动配置类自动配置了处理规则,给容器中注册了多种组件 errorAttributes组件,类型为DefaultErrorAttributes.这个组件定义错误页面中可以包含哪些数据 basicErrorController组件,类型为BasicErrorController.处理默认/error路径的请求,new一个id为error的ModelAndView对象来响应页面 error组件,类型为View.响应的是默认错误页面 b

  • SpringBoot使用自动配置xxxAutoConfiguration

    常用的类: @ConditionalOnProperty(name = "use.redis.session.store", havingValue = "true") @ConditionalOnClass(Session.class) @AutoConfigureAfter(RedisAutoConfiguration.class) @ConditionalOnWebApplication @ConditionalOnMissingBean(RedisHttpS

  • springboot自动配置原理解析

    前言 小伙伴们都知道,现在市面上最流行的web开发框架就是springboot了,在springboot开始流行之前,我们都用的是strust2或者是springmvc框架来开发web应用,但是这两个框架都有一个特点就是配置非常的繁琐,要写一大堆的配置文件,spring在支持了注解开发之后稍微有些改观但有的时候还是会觉得比较麻烦,这个时候springboot就体现出了它的优势,springboot只需要一个properties或者yml文件就可以简化springmvc中在xml中需要配置的一大堆

  • 继承WebMvcConfigurationSupport后自动配置不生效及如何配置拦截器

    网上有很多文章说从spring boot2.0之后在构造spring配置文件时建议推荐直接实现WebMvcConfigurer或者直接继承WebMvcConfigurationSupport ,经测试实现WebMvcConfigurer是没问题,但继承WebMvcConfigurationSupport类是会导致自动配置失效的. 一.继承WebMvcConfigurationSupport类是会导致自动配置失效的原因 在spring boot的自定义配置类继承 WebMvcConfigurati

  • SpringBoot自动配置原理分析

    目录 前言 一.启动类 1.1.@SpringBootConfiguration 1.2.@EnableAutoConfiguration 1.3.@ComponentScan 1.4.探究方向 二.@SpringBootConfiguration 三.@EnableAutoConfiguration 3.1.@AutoConfigurationPackage 3.2.@Import(AutoConfigurationImportSelector.class) 3.2.1.getCandidat

  • SpringBoot自动配置特点与原理详细分析

    目录 一.SpringBoot是什么 二.SpringBoot的特点(核心功能) 三.SpringBoot的自动配置原理 1. @SpringBootApplication 2. @SpringBootConfiguration 3. @EnableAutoConfiguration 4. @ComponentScan 四.核心原理图 五.常用的Conditional注解 一.SpringBoot是什么 Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Sprin

  • 基于SpringBoot核心原理(自动配置、事件驱动、Condition)

    前言 SpringBoot是Spring的包装,通过自动配置使得SpringBoot可以做到开箱即用,上手成本非常低,但是学习其实现原理的成本大大增加,需要先了解熟悉Spring原理.如果还不清楚Spring原理的,可以先查看博主之前的文章,本篇主要分析SpringBoot的启动.自动配置.Condition.事件驱动原理. 正文 启动原理 SpringBoot启动非常简单,因其内置了Tomcat,所以只需要通过下面几种方式启动即可: @SpringBootApplication(scanBas

随机推荐