为什么大网站的百度快照更新速度慢还排第一,推广项目,句容网站制作哪家好,wordpress去目录 前言阅读对象阅读导航前置知识什么是自动配置0.1 基本概念0.2 SpringBoot中的【约定大于配置】0.3 从SpringMVC看【约定大于配置】0.4 从Redis看【约定大于配置】0.5 小结 笔记正文一、EnableAutoConfiguration源码解析二、SpringBoot常用条件注解源码解析2.1 自定义条件注… 目录 前言阅读对象阅读导航前置知识什么是自动配置0.1 基本概念0.2 SpringBoot中的【约定大于配置】0.3 从SpringMVC看【约定大于配置】0.4 从Redis看【约定大于配置】0.5 小结 笔记正文一、EnableAutoConfiguration源码解析二、SpringBoot常用条件注解源码解析2.1 自定义条件注解2.2 ConditionalOnClass原理解析2.3 ConditionalOnBean原理解析 三、SpringBoot之Mybatis自动配置源码解析四、SpringBoot之AOP自动配置类 学习总结感谢 前言
想要搞懂【自动配置】需要当前系列前两篇笔记内容打底。不过我上一篇笔记写的不好没有什么突出的重点主要也是当时跟着课程看了源码之后也没发现什么特别的直到在看自动装配源码的时候才后知后觉遗漏了一些重要的知识点。但是总体来说不影响这一节课的笔记记录吧。 另外说到【自动配置】以前我总是掉入一个思维陷阱里面认为这里说到的配置就是xml配置这让我在理解【自动配置】的时候总是走了一些弯路所以这里也是给大家提前提个醒了这个配置不仅仅是xml配置而已而是包括任何形式的对服务接口的配置。
阅读对象
对自动配置感兴趣的朋友
阅读导航
系列上一篇文章《【微服务专题】Spring启动过程源码解析》
前置知识
什么是自动配置
我们说起SpringBoot总会不自觉的联想到自动配置、约定大于配置等标签但说实在我是有一点困惑的这个【约定和配置】到底是什么意思或者说它们具体指的是哪些内容啊 我在想像我这种只是用过那么一年多SSM/SSH甚至完全没有经历过的人来说是很难理解的。虽然我也确实经历过SSM/SSH但那时候初出茅庐根本就没在意过这些玩意好吧…
不过话说回来后面再回来继续做Java的时候已经是SpringBoot的时代了嘛所以单从片面印象来说的话SpringBoot确实方便了很多。最最最直观的就是启动给我的感觉启动一个web应用跟简单运行了一个main方法一样便捷。而在以前SSM/SSH时代各种眼花缭乱的xml配置还有那个令人烦躁的tomcat配置就已经让我很难受了。
好吧不懂嘛于是我就去稍微学习了一下。下面我就按照我自己的理解再拼上一些百度的、起码能说服我自己的答案给大家说道说道。另外也想举一个真正直观的例子给大家说说【约定和配置】到底使了什么魔法
0.1 基本概念
【约定大于配置】是一种开发思想、设计理念它强调使用默认约定和规则减少开发者需要做的【显式】配置。根据这一原则大部分情况下开发者只需关注那些【不符合默认约定】的配置而不需要为每个细节都进行显式配置。。 开天眼给大家说一下既然结果是减少了需要程序员【显示】配置的工作量那反过来就证明了在SpringBoot之前的时代有一些配置是不得不必须需要程序员去配置的 另外这里说的【配置】不仅仅是指xml配置准确来说是对引入的服务的所有形式的配置xml只是一种形式而已。我们还可以是txt、yml还有java文件的配置方式。 我认为这个结论很重要我后面研究案例就是往这方向去看的 综上所述可以这样简单地理解【约定】和【配置】
默认规则【显示】配置不得不设置的配置 / 没办法使用默认规则的配置。再重申一遍这里说的【配置】不仅仅是指xml配置准确来说是对引入的服务的所有形式的配置xml只是一种形式而已。我们还可以是txt、yml还有java文件的配置方式。
这个理念有如下显著的优势
提高开发效率 通过遵循默认约定开发者可以快速启动项目并进行开发无需花费大量时间在繁琐的配置上减少决策负担 【约定大于配置】减少了开发者需要做出的决策使开发过程更加流畅不需要在每个细节上做出选择减少错误 默认约定可以减少配置错误的机会因为开发者只需要在特定情况下进行配置从而降低了出错的可能性
0.2 SpringBoot中的【约定大于配置】
我们都知道SpringBoot是基于Spring的严格来说SpringBoot的出现其实是为了降低Spring的使用门槛。
使用maven的目录结构。默认有src-main-resources文件夹存放资源配置文件src-main-java存放项目java源码target文件夹存放编译、打包内容其实Maven的设计本身就是遵循【约定大于配置】的原则 这是约定的一种通过约定这些内容使得项目结构统一减少了开发人员学习成本。 试想一下如果我们在不同的公司他们的项目结构五花八门甚至没有src/main/resources没有src/main/java等目录你学习成本是不是变高了博主之前写过2、3年C/C那时候接触的项目就是这个鸟样子的都是自定义资源存放目录打包目录源码目录真的吐血… … 我转战Java很大一个原因就是奔着Java的规范性去的。当然我现在相当后悔当时忍一忍就不会掉进Java的坑里了 使用application.properties/yml文件设置配置内容 这也是一种约定拒绝程序员五花八门的配置文件 默认使用Tomcat容器 接触过SSM吗SSM项目通常来说需要额外配置启动一个Tomcat然后将SSM项目打包部署到Tomcat上 而在SpringBoot中我们启动项目就跟运行一个普通的main函数一样 提供了大量的自动配置接口自动配置类注解等帮助程序员配置。严格来说自动配置接口以及注解等都是为了自动配置类服务的。SpringBoot提供的大量自动配置类在里面默认设置了很多值用以配置第三方接口服务这些默认配置甚至能让开发做到开箱即用只有一些不得不需要用户设置的内容才需要开发人员自己设置。这就是上面概念所谓的开发者只需要关注那些不符合默认约定的配置的意义。 这是SpringBoot【约定大于配置】的重要实现。我们先稍微解释一下这些所谓的接口、类、注解是指什么 自动配置接口AutoConfigurationImportFilter、AutoConfigurationImportListener等自动配置类DispatcherServletAutoConfiguration、HttpEncodingAutoConfiguration等注解诸如AutoConfiguration、AutoConfigurationPackage等 上述我只是简单列举了一些内容而已其实具体的可以看org.springframework.boot:spring-boot-autoconfigure这个包。里面就是SpringBoot为大家做自动配置提供的默认配置和相关接口 0.3 从SpringMVC看【约定大于配置】 说实在SpringMVC我不是很熟悉所以我不是很保证自己说的是对的在网上也没看到非常令人信服的答案。但是关于【约定大于配置】的体现我觉得还是正确的。 有人说spring-boot-starter-web其实就是免配置的SSM。在SSM时代我们想要开发一个web应用免不了如下配置
新增web.xml在里面配置前端控制器DispatcherServlet、视图解析器ViewResolver、过滤器等新增核心配置文件**-servlet.xmlTomcat容器的配置等等…
其实说需要新增这种那种xml配置是有点狭隘的说法我前面说过了xml只是其中一种配置形式而已。 准确来说传统的SSM项目需要我们开发人员显式、准确地向Spring容器注册DispatcherServlet、ViewResolver、SqlSessionFactoryBean、DriverManagerDataSource。 如果我们没有【显式】地去声明、注册这些Bean那我们项目直接启动失败他会说找不到这个找不到那个。但是在SpringBoot中我们只需要在pom中引入spring-boot-starter-web就可以了这个jar包会自动向Spring中注册上述关键bean。
怎么注册我们简单看一下关于SpringMVC的自动配置类。
1WebMvcAutoConfiguration.javaSpringMVC的自动配置入口 在这里我们无需关心上面的诸多注解的具体含义先具体意义我会在后面的源码解析中介绍。 但是可以预见的是在某种情况下spring-boot-stater-web会进入DispatcherServletAutoConfiguration.class里面
2DispatcherServletAutoConfiguration.java在这里有一个Bean暂不关心他什么时候会被触发但至少可以预见的是在某种情况下DispatcherServletAutoConfiguration类会向Spring中注册一个DispatcherServlet类型的bean 啊对的本质上就是如此而已。SpringBoot的自动配置实际上就是SpringBoot的源码中预先写好了一些配置类预先定义好了一些Bean我们在用SpringBoot时这些配置类就已经在我们项目的依赖中了而这些自动配置类或自动配置Bean到底生不生效就看具体所指定的条件了。
不过还有一点需要说明那就是SpringBoot可不是简简单单的给你注册了一个默认的bean它还会给部分【符合约定】的基础参数设置默认的、至少有意义的、比较符合一般应用的初始值来初始化bean。这个就是SpringBoot提供的各种XxxProperties.java。例如WebMvcProperties O对了说到了这个XxxProperties.java文件其实它也是约定的一种体现。以前SSM我们相当于直接配置了服务接口的一些参数而在SpringBoot里面我们直接配置的其实是XxxProperties然后再由SpringBoot使用XxxProperties配置属性去初始化服务接口参数。而通常这些XxxProperties对应的是application.properties里面的一些配置内容。 相比起直接配置服务接口参数XxxProperties可读性更强使用也更简单。
0.4 从Redis看【约定大于配置】
想到SpringMVC可能很多人都不熟悉所以这边再介绍一下Redis是怎么实现【约定大于配置】的。其实大体思路跟上面差不多
找到有哪些不得不需要程序员配置的类找到Redis自动配置类看看Redis的相关自动配置XxxProperties文件
如下其实1和2基本上都可以在自动配置类里面体现出来 当然不止这两个类还有一些类在上面的Import({ LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class })被声明这俩是不同的客户端而已给大家贴部分代码截图如下 从上面这两张代码截图图可以看出SpringBoot默认使用Lettuce作为客户端。只有我们在项目中引入了JedisJedis客户端才会生效。
再然后就是这个RedisProperties文件是SpringBoot提供给我们的直接配置类
0.5 小结
OK关于SpringBoot中的【约定大于配置】就介绍到这里了。那他们是怎么实现的呢有经验的朋友或者稍微细心的朋友估计也从上图看到了【自动配置】主要是靠下图这些类、接口、注解实现的后面我们就来稍微研究一下里面的源码实现。org.springframework.boot:spring-boot-autoconfigure包下
笔记正文
一、EnableAutoConfiguration源码解析
说实在水平有限解析不了很深层次。先来看看该注解声明
/*** 启用Spring应用程序上下文的自动配置尝试猜测和配置您可能需要的bean。* 自动配置类通常基于您的类路径和您定义的bean来应用。例如如果您的类路径中有* tomcat-embedded.jar那么您可能需要一个TomcatServletWebServerFactory* (除非您已经定义了自己的ServletWebServerFactory bean)。* 当使用SpringBootApplication时上下文的自动配置是自动启用的因此添加这个注释没有额外的效果。* 自动配置试图尽可能地智能并且会随着您定义更多自己的配置而后退。* 您始终可以手动排除()任何您不想应用的配置(如果您没有访问权限请使用excludeName())。* 你也可以通过spring.autoconfigure.exclude属性排除它们。* 自动配置总是在用户定义bean注册之后应用。* 用EnableAutoConfiguration注释的类包通常通过SpringBootApplication* 具有特定的意义通常被用作“默认”。例如它将在扫描Entity类时使用。通常建议将* EnableAutoConfiguration(如果不使用SpringBootApplication)放在根包中* 以便可以搜索所有子包和类。* 自动配置类是常规的Spring Configuration bean。它们是使用importcandidate和* springfactoresloader机制定位的(与这个类相关)。通常自动配置bean是条件bean(最常使用* ConditionalOnClass和ConditionalOnMissingBean注释)。*/
Target(ElementType.TYPE)
Retention(RetentionPolicy.RUNTIME)
Documented
Inherited
AutoConfigurationPackage
Import(AutoConfigurationImportSelector.class)
public interface EnableAutoConfiguration {/*** Environment property that can be used to override when auto-configuration is* enabled.*/String ENABLED_OVERRIDE_PROPERTY spring.boot.enableautoconfiguration;/*** Exclude specific auto-configuration classes such that they will never be applied.* return the classes to exclude*/Class?[] exclude() default {};/*** Exclude specific auto-configuration class names such that they will never be* applied.* return the class names to exclude* since 1.3.0*/String[] excludeName() default {};}我把官方声明注释也一起搬过来了。我稍微解读一下
EnableAutoConfiguration 用来启用Spring的自动配置功能它核心原理主要在于推测推测程序要需要的Bean。比如我们的项目jar包中依赖了Jetty那么推测你可能需要Jetty容器项目依赖了redis那就推测你需要Redis通常自动配置bean会与Conditional注解一起工作自动配置的实现使用了SPI机制
OK回到正文。EnableAutoConfiguration中有两个很明显的引用
AutoConfigurationPackage
Import(AutoConfigurationImportSelector.class)所以不难看出来自动配置的核心实现逻辑就在这两个类里面了。
1AutoConfigurationPackage 点进去看显然核心实现还是在于Import(AutoConfigurationPackages.Registrar.class) Import注解可以简单的理解为直接导入一个bean 再点进去看核心主要是registerBeanDefinitions方法注册Bean图纸。这个方法会在哪里调用呢大概是在Spring容器初始化之后实例化所有Bean之前。 其实也没啥好说的了他的作用很简单就是向Spring容器注册了一个BeanDefinition叫做autoConfigurationPackages这个BeanDefinition里面有一个重要属性属性存放的是当前扫描包路径有啥用呢大概是为了方便第三方扫描的时候能够方便获取。比如Mybatis自动配置类扫描的时候就用到了这个BeanDefinition。 2Import(AutoConfigurationImportSelector.class) 老规矩看里面这个AutoConfigurationImportSelector.class。他的定义如下
// DeferredImportSelector处理自动配置。
// 如果需要EnableAutoConfiguration的自定义变体这个类也可以被子类化。
public class AutoConfigurationImportSelector implements DeferredImportSelector, BeanClassLoaderAware,ResourceLoaderAware, BeanFactoryAware, EnvironmentAware, Ordered {这个类的核心在于实现了DeferredImportSelector他的类继承图如下 整个方法的入口其实有点难找需要看了源码才知道具体在哪里会被调用呢跟上面一样【大概是在Spring容器初始化之后实例化所有Bean之前】。但这并不是篇内容的核心所以我直接贴图调用处 可以看到最终实现还是由红框内的getAutoConfigurationEntry通过方法翻译函数名为获取自动配置入口。从这里开始就有点复杂了SPI的实现就在里面 步骤解析
获取SpringBootApplication注解上的排除路径配置 使用SPI技术获取所有候选的配置类这应该是最核心的实现了 这里会去本包包括所有依赖的jar包下的META-INF/spring.factories下加载EnableAutoConfiguration和AutoConfiguration注解的类 去重加载排除路径查找需要被去除自动配置类然后去除过滤一遍判断所有自动配置类上面的条件注解是否生效。对于不生效的自动配置类也没必要再去走后面的逻辑了发布自动配置类导入事件
3源码入口 对上面提到的两个核心类被Spring容器调用时机感兴趣的朋友可以看看ConfigurationClassPostProcessor类。对Spring源码不熟悉或者生命周期不熟悉的朋友估计有点压力。我也有点压力…
二、SpringBoot常用条件注解源码解析
SpringBoot中的常用条件注解有
ConditionalOnBean是否存在某个某类或某个名字的BeanConditionalOnMissingBean是否缺失某个某类或某个名字的BeanConditionalOnSingleCandidate是否符合指定类型的Bean只有一个ConditionalOnClass是否存在某个类ConditionalOnMissingClass是否缺失某个类ConditionalOnExpression指定的表达式返回的是true还是falseConditionalOnJava判断Java版本ConditionalOnWebApplication当前应用是不是一个Web应用ConditionalOnNotWebApplication当前应用不是一个Web应用ConditionalOnPropertyEnvironment中是否存在某个属性当然我们也可以利用Conditional来自定义条件注解
条件注解是可以写在类上和方法上的如果某个条件注解写在了自动配置类上那该自动配置类会不会生效就要看当前条件能不能符合或者条件注解写在某个Bean修饰的方法上那这个Bean生不生效就看当前条件符不符合。
具体原理是
Spring在解析某个自动配置类时会先检查该自动配置类上是否有条件注解如果有则进一步判断该条件注解所指定的条件当前能不能满足如果满足了则继续解析该配置类如果不满足则不进行解析了也就是配置类所定义的Bean都得不到解析也就是相当于没有这些Bean了。同理Spring在解析某个Bean的方法时也会先判断方法上是否有条件注解然后进行解析如果不满足条件则该Bean不会生效
2.1 自定义条件注解
SpringBoot中众多的条件注解都是基于Spring中的Conditional来实现的所以这里我们演示一下如何使用Conditional自定义一个我们的条件注解。
先来看下Conditional注解的定义
/*** * 指示组件只有在所有指定条件匹配时才有资格注册。* 条件是可以在注册bean定义之前以编程方式确定的任何状态(有关详细信息请参阅条件)。* Conditional注释可以以以下任何一种方式使用:* 在任何直接或间接用Component注释的类(包括Configuration类)上作为类型级注释* 作为元注释用于组合自定义构造型注释* 作为任何Bean方法上的方法级注释* 如果Configuration类被标记为Conditional那么与该类关联的所有Bean方法、Import注释和ComponentScan注释* 将受这些条件的约束。*/
Target({ElementType.TYPE, ElementType.METHOD})
Retention(RetentionPolicy.RUNTIME)
Documented
public interface Conditional {/*** All {link Condition} classes that must {linkplain Condition#matches match}* in order for the component to be registered.*/Class? extends Condition[] value();}根据定义我们在用Conditional注解时需要指定一个或多个Condition的实现类所以我们先来提供一个实现类
public class ShenCondition implements Condition {Overridepublic boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {MapString, Object component metadata.getAnnotationAttributes(org.springframework.stereotype.Component);System.out.println(下面开始打印condition里面的内容);System.out.println(component);Object value component.get(value);return value.toString().equals(shen);}
}上面这个实现类很简单就是获取被Conditional(ShenCondition.class)注解的类上获取它Component上的注解值如果值是shen那就返回true否则bean注册不成功。接下来就是自定义一个我们自己的注解
Target({ ElementType.TYPE, ElementType.METHOD })
Retention(RetentionPolicy.RUNTIME)
Documented
Conditional(ShenCondition.class)
public interface ShenConditional {
}测试用例如下
ShenConditional
Component(shen)
public class ShenWorker {public String sayHello() {return hello;}
}SpringBootApplication(scanBasePackages org.example.springboottest)
public class ShenMyApplication {public static void main(String[] args) {ConfigurableApplicationContext context SpringApplication.run(ShenMyApplication.class);ShenWorker shen (ShenWorker) context.getBean(ShenWorker.class);System.out.println(------------------------);System.out.println(shen.sayHello());}
}此时运行控制台输出 把上面的ShenWorker 的Component值改成其他如Component(shenWorker)运行则输出如下 报错了NoSuchBeanDefinitionException。 我想到了这里大家应该多少知道Conditional注解的作用了接下来我们挑其中一两个SpringBoot声明的条件注解看一下源码剖析一下它是怎么实现的。
2.2 ConditionalOnClass原理解析 ConditionalOnClass注解的作用是校验是否存在某个类。 Spring这种优秀源码通常注释都是很完善的我们先来看看它们是怎么定义的
/*** Conditional当且仅当指定的类在类路径上时才匹配成功** value()可以在Configuration类上安全地指定因为在加载类之前* 会使用ASM解析注释元数据。当放置在Bean方法上时需要特别注意* 考虑在单独的Configuration类中隔离条件特别是如果方法的返回类型与条件的目标匹配*/
Target({ ElementType.TYPE, ElementType.METHOD })
Retention(RetentionPolicy.RUNTIME)
Documented
Conditional(OnClassCondition.class)
public interface ConditionalOnClass {/*** 必须设置的class信息。* 因为这个注释是通过加载类字节码来解析的classLoader.loadClass* 当且仅当这个注解直接作用在bean上而不是当这个注解被用作组合的元注释时* 在这里指定最终可能不在classpath上的类是安全的不会报错。* 想要将此注解用作元注释那么就只使用name属性*/Class?[] value() default {};/*** 必须设置的类全限定名*/String[] name() default {};
}根据我们自定义注解经验该注解的实现肯定是在Conditional(OnClassCondition.class)的OnClassCondition.class中。 顺便在这里介绍一下怎么用idea追踪代码吧。
1寻找关键实现类 首先我们知道OnClassCondition.class实现自Condition接口主要是实现里面的matches()方法。虽然咱还不知道它是在哪里被Spring调用的但起码他肯定是会被调用的对吧所以我们先跳到OnClassCondition.class文件打开它的继承图如下所示 可以发现它继承或者实现了各种各样的接口其中一个是Condition。那OK 我们在回到OnClassCondition.class文件alft7打开代码结构图然后在右上角点击查看继承过来的属性、方法如下所示 如上图所示绿色框内灰色的即为继承过来但是没有重写的方法。可以看到Condition接口的matches方法就没有被重写过那说明父类中肯定有默认的实现类点击一下会跳到SpringBootCondition类中它的默认实现方式如下 可以看到最重要的是红框内的2行代码。点击getMatchOutcome发现这是一个抽象方法所以又回到OnClassCondition.class文件中查找一下看看是否实现或者重写了该方法。最后发现如下 重写了再结合之前的代码可以判断出来这里就是OnClassCondition类的逻辑实现核心。上面的代码其实也不难基本上通过方法名就知道啥意思了。主要原理就是使用反射工具根据全限定名去JVM加载类如果能加载成功那就证明class存在反之则不存在。 特别注意ConditionalOnClass和ConditionalOnMissingClass注解的核心实现都是这个类的这个方法 2.3 ConditionalOnBean原理解析
点击查看ConditionalOnBean注解会发现逻辑是在OnBeanCondition.class中然后按照上面的思路也会发现它跟前面的注解实现套路基本一致逻辑也是在getMatchOutcome中如下 这个源码也很简单通过阅读注解接口的各种字段信息就能推断出来具体过程。总的来说就是根据bean是否存在于Spring容器中来返回结果。 特别注意ConditionalOnBean和ConditionalOnSingleCandidateConditionalOnMissingBean注解的核心实现都是这个类的这个方法 三、SpringBoot之Mybatis自动配置源码解析
在我们的项目pom中导入如下 dependencygroupIdorg.mybatis.spring.boot/groupIdartifactIdmybatis-spring-boot-starter/artifactId/dependency我们就会看到我们项目依赖中出现以groupIdartifactId命名的jar包了如下 看到这里需要说明的是SpringBoot不总是提供所有你知道的服务的自动配置类有时候需要厂商自己去实现。就好比这个Mybatis就是自己实现了自动配置类让用户尽量做到开箱即用。 对的通常第三方在写自动配置的时候命名风格皆是如此。而在里面的MybatisAutoConfiguration即为Mybatis的自动配置类。通过源码我们可以发现在里面注册了多个bean当然是有条件的 上面的意思是在Spring中如果没有SqlSessionFactory这个类型的bean则注册当前bean 另一个注册的bean如下 最核心的一个还是在自动配置类下面有一个这玩意 这个 Bean的作用是如果没有其他显式的注册Mapper扫描映射器那就注册一个默认的Mapper扫描映射器扫描路径跟SpringBoot扫描路径一致。说到这里是不是有朋友对Mybatis如何实现把接口转换成bean这个操作感兴趣呢大家伙可以看看按照下面这个轨迹从1-9-AB自上而下去看看但是需要一些Spring功底。源码入口MybatisAutoConfiguration.AutoConfiguredMapperScannerRegistrar#registerBeanDefinitions我有一点功底但不算很扎实只能勉强看个大概 总的来说它的原理大致如下注意这里是指默认自动配置类情况下如果使用了MapperScan注解情况略有不同
Mybatis自动配置类会向Spring容器注册一个扫描器Bean定义根据Bean定义初始化扫描器属性。默认扫描路径是当前SpringBoot的扫描路径Mybatis会修改扫描到Mapper接口的BeanDefinition生成Bean的图纸关键代码在org.mybatis.spring.mapper.ClassPathMapperScanner#processBeanDefinitionsMybatis会修改注册成为Bean的条件原本接口类是不能够被注册成为Bean的但是通过修改条件让其通过了判断具体怎么生成的Bean主要用到了Spring提供的FactoryBean再然后是用到了Jdk的动态代理生成代理类。感兴趣的要自己去看看Spring的一些核心概念了
四、SpringBoot之AOP自动配置类
老套路了AOP毕竟是Spring本家产品所以他的自动配置类肯定在本包下org.springframework.boot:spring-boot-autoconfigure。 源码如下
public class AopAutoConfiguration {Configuration(proxyBeanMethods false)ConditionalOnClass(Advice.class)static class AspectJAutoProxyingConfiguration {Configuration(proxyBeanMethods false)// 开启AOP的注解使用JDK动态代理EnableAspectJAutoProxy(proxyTargetClass false)// spring.aop.proxy-target-classfalse时才生效ConditionalOnProperty(prefix spring.aop, name proxy-target-class, havingValue false)static class JdkDynamicAutoProxyConfiguration {}Configuration(proxyBeanMethods false)// 开启AOP的注解使用CGLIB动态代理EnableAspectJAutoProxy(proxyTargetClass true)// spring.aop.proxy-target-classtrue时生效或者没有配置spring.aop.proxy-target-class时默认也生效ConditionalOnProperty(prefix spring.aop, name proxy-target-class, havingValue true,matchIfMissing true)static class CglibAutoProxyConfiguration {}}Configuration(proxyBeanMethods false)// 没有aspectj的依赖但是又要使用cglib动态代理ConditionalOnMissingClass(org.aspectj.weaver.Advice)ConditionalOnProperty(prefix spring.aop, name proxy-target-class, havingValue true,matchIfMissing true)static class ClassProxyingConfiguration {Beanstatic BeanFactoryPostProcessor forceAutoProxyCreatorToUseClassProxying() {return (beanFactory) - {if (beanFactory instanceof BeanDefinitionRegistry) {BeanDefinitionRegistry registry (BeanDefinitionRegistry) beanFactory;// 注册InfrastructureAdvisorAutoProxyCreator从而开启Spring AOP// EnableAspectJAutoProxy会注册AnnotationAwareAspectJAutoProxyCreator也会开启Spring AOP但是同时有用解析AspectJ注解的功能AopConfigUtils.registerAutoProxyCreatorIfNecessary(registry);AopConfigUtils.forceAutoProxyCreatorToUseClassProxying(registry);}};}}
}学习总结
终于理解了【约定大于配置】是什么意思跟踪学习了Mybatis是如何实现自动配置包括怎么让mapper接口变成一个可实例化的bean的
感谢
感谢阿里云社区的文章《探索Spring Boot中的原则约定大于配置》 感谢百度大佬【作者编程师兄】的文章《SpringBoot约定大于配置到底是什么意思》
