这篇文章主要介绍分析SpringBoot MVC自动配置失效的原因是什么,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
引出问题
上面是SpringBoot MVC的自动配置,问题是这样的,当我们需要自己配置MVC时,有三种选择:
在老版本中我们常用的做法就是继承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
以上是分析SpringBoot MVC自动配置失效的原因是什么的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。