AOP的核心成员是如何被被加载的?
本篇我们主要分析使用xml的逻辑,如果使用注解,增加注解处理类即可(ConfigurationClassPostProcessor)
拿之前分析循环的时候举的例子🌰,它的日志切面就是通过xml进行配置的(配置文件📃内容如下,完整测试代码可参考【实践向】当移除了三级缓存…… 中的示例代码)
![](https://img-blog.csdnimg.cn/img_convert/02c01005c253d3898b3e5202b7122b8f.png)
通过ApplicationContext applicationContext = new ClassPathXmlApplicationContext("circulate.xml");启动容器
![](https://img-blog.csdnimg.cn/img_convert/deeed82f3be69cc51c8c05c77c9a4683.png)
进入refresh()方法后,先调用prepareRefresh()方法进行的是容器刷新前的准备工作,这里的准备工作大致包括5个内容:
设置容器的启动时间
设置活跃状态为true
设置关闭状态为false
获取Environment对象,并加载当前系统的属性值到Environment对象中
准备监听器和事件的集合对象(默认为空)
在准备工作完成后,开始了下面的创建容器的流程
创建容器
进入方法obtainFreshBeanFactory(),开始Spring容器的创建
![](https://img-blog.csdnimg.cn/img_convert/364e52a1630bd15dc26f178adf4f30ed.png)
可以看到此时创建的是上下文对象是ClassPathXmlApplicationContext
![](https://img-blog.csdnimg.cn/img_convert/5ae7a8d6a6438bfaddf5cb23f28da993.png)
接着进入方法refreshBeanFactory()中,开始BeanFactory的初始化以及XML配置文件的读取和解析
![](https://img-blog.csdnimg.cn/img_convert/06b9fc35207e3545867dfe2052e9bf90.png)
读取并解析XML配置文件📃
![](https://img-blog.csdnimg.cn/img_convert/dd1f4beea99b1ca814cfa4914bf64ce0.png)
进入loadBeanDefinitions()
![](https://img-blog.csdnimg.cn/img_convert/f380dc843f491848be6063be91136ca3.png)
![](https://img-blog.csdnimg.cn/img_convert/3e573d66bb5e8738191a533d9302386d.png)
![](https://img-blog.csdnimg.cn/img_convert/c1ddcdc0f5098f7f364afb6cf488461d.png)
![](https://img-blog.csdnimg.cn/img_convert/26a0a4f9a71bfb54d7e2b943496bcd4c.png)
终于看到了咱们的doLoadBeanDefinitions() ,正式开始读取+解析标签🏷️的逻辑
![](https://img-blog.csdnimg.cn/img_convert/a588c1a2c06b22965305d2384889fb96.png)
registerBeanDefinitions()
![](https://img-blog.csdnimg.cn/img_convert/585d7d5be5a9a1585a454aee1fc2a363.png)
![](https://img-blog.csdnimg.cn/img_convert/c59ae2439f40bb4b691c385734e02a7e.png)
进入doRegisterBeanDefinition()(没错、do-开头的方法都是干实事的~)
![](https://img-blog.csdnimg.cn/img_convert/5279ec497800913243fde3866941bdee.png)
开始重头戏(。・ω・。)ノ
![](https://img-blog.csdnimg.cn/img_convert/8820d8caef5e9bbd1e5670d30f0ce817.png)
进入parseBeanDefinitions(),方法中对于 Element 的处理主要分为两种类型:
parseDefaultElement
parseCustomElement
找到对应的handler
<aop:config>就属于自定义元素类型,所以我们进入parseCustomElement()方法中
![](https://img-blog.csdnimg.cn/img_convert/0df0d7d4889261f57af7b8c0f83546ed.png)
进入parseCustomElement()
![](https://img-blog.csdnimg.cn/img_convert/85475eef1e6670d59f6f99ae7ace1b85.png)
我们可以看到,此时的处理器handler为AopNamespaceHandler
![](https://img-blog.csdnimg.cn/img_convert/471e7f277e1eb1f6218c3cf2eb7d8898.png)
按照案例代码,我们进入了NamespaceHandlerSupport接口中,重写了parse
![](https://img-blog.csdnimg.cn/img_convert/1e0ae86c87718c468bb433a539254ca2.png)
进入其一个实现类NamepaceHandlerSupport中
![](https://img-blog.csdnimg.cn/img_convert/01b94df04ff9d9aed953bbc3a39c2cc8.png)
由于parser != null为true,再次进入名为parse()的方法中
![](https://img-blog.csdnimg.cn/img_convert/1f1b4250dea33d28e988e4f888e7521f.png)
这里主要进行了两个步骤的处理:
注册自动代理模式创建器
解析<aop:config>下的子节点
POINTCUT
ADVICE
ASPECT
我们依次来看看
第一个步骤:【注册自动代理模式创建器】configureAutoProxyCreator()
![](https://img-blog.csdnimg.cn/img_convert/3809793ca9cf83b748addd4f8f27b1d7.png)
进入方法configureAutoProxyCreator()
![](https://img-blog.csdnimg.cn/img_convert/8d4344e48130bb03f8666482d8e0b8e8.png)
此时集合containingComponents中只有一个元素:"aop:config"
进入registerAspectJAutoProxyCreatorIfNecessary()
![](https://img-blog.csdnimg.cn/img_convert/fdcc8fa6fb5d83f8e260d74638680221.png)
registerOrEscalateApcAsRequired()
![](https://img-blog.csdnimg.cn/img_convert/de6044c3f4c0d6c501ffa16fb1d01aed.png)
进入registerOrEscalateApcAsRequired()
![](https://img-blog.csdnimg.cn/img_convert/ac0e50e8b2b856cd9d7071b17228e11d.png)
如果已经存在了自动代理创建器,且存在的自动代理创建器与当前不一致,那么需要根据优先级来判断下到底需要使用哪个;如果已经存在了自动代理创建器,且存在的自动代理创建器与当前一致,则无需再次创建,返回null即可
![](https://img-blog.csdnimg.cn/img_convert/b3d2e8c7c4bb10e937161a1c39673800.png)
下面的变量表中可以看到,这里注册的Bean名为org.springframework.aop.config.internalAutoProxyCreator的beanDefinition;并且其中的BeanDefinition的具体Class类为AspectJAwareAdvisorAutoProxyCreator
方法registerOrEscalateApcAsRequired()执行到最后的registerBeanDefinition()时,当前的BeanDefinition(也就是AspectJAwareAdvisorAutoProxyCreator的BeanDefinition)就已经注册成功了
由下图的静态代码块中也同样添加了InfrastructureAdvisorAutoProxyCreator和AnnotationAwareAspectJAutoProxyCreator这两个类,因此可以推断出他俩的注册流程与AspectJAwareAdvisorAutoProxyCreator类似
![](https://img-blog.csdnimg.cn/img_convert/95b8394b7ac3f066451a8fa4bd1f4163.png)
那么问题来了:AspectJAwareAdvisorAutoProxyCreator跟我们熟悉的那些BeanPostProcessor、Aware等等有什么关系么?
(*≧ω≦)我们看下类关系图(下图中右下角的就是AspectJAwareAdvisorAutoProxyCreator)
![](https://img-blog.csdnimg.cn/img_convert/5f7908cdd4dc774d8e9f5b0816c52a20.png)
useClassProxyingIfNecessary()
![](https://img-blog.csdnimg.cn/img_convert/3cd066e94b60ea62977da9786028cbf5.png)
方法中主要是对proxy-target-class和expose-proxy这两个属性进行处理
![](https://img-blog.csdnimg.cn/img_convert/097b5144010f647da7d9a88e4a7dcd03.png)
如果被代理的目标对象实现了至少一个接口,就会使用JDK动态代理,该目标类型实现的接口都会被代理;如果没有实现任何接口,则创建一个Cglib代理对象
registerComponentIfNecessary()
![](https://img-blog.csdnimg.cn/img_convert/9f61a4c492eb7bec54c5cef084f825e7.png)
最后调用方法registerComponentIfNecessary()注册对应的组件
![](https://img-blog.csdnimg.cn/img_convert/a2c386c8f070dd1cd440af97216267aa.png)
接着回到parse()方法中,可以看到此时<aop:config>还是null
![](https://img-blog.csdnimg.cn/img_convert/87c12f1ee52fac4ea68573de4100a5ee.png)
第二个步骤:解析<aop:config>下的子节点
继续解析<aop:config>子节点下的
<aop:pointcut>
<aop:advice>
<aop:aspect>
![](https://img-blog.csdnimg.cn/img_convert/0f2ce66b8eabf62e3c1880c9eae5b3f5.png)
在这里会根据获取到的localName进入不同的if条件语句,进而执行不同的解析方法
parsePointcut()
parseAdvisor()
parseAspect()
下面我们按照我们的测试代码中的XML配置(如下图)捋一遍流程(。・ω・。)ノ
![](https://img-blog.csdnimg.cn/img_convert/711236f995373735d995d4978603f3ca.png)
由于获取到的localName为"aspect",满足ASPECT.equals(localName)为true的条件,所以进入parseAspect()方法中
![](https://img-blog.csdnimg.cn/img_convert/7635fe8a5bdb1085d0877997269732c4.png)
parseAspect()
![](https://img-blog.csdnimg.cn/img_convert/85256abf555bdb5cfadefa08b8e16a9a.png)
先获取<aop:aspect>的两个属性:
id属性
ref属性(代表切面,必须配置)
![](https://img-blog.csdnimg.cn/img_convert/a3608098db8e3574ef481fb46d9ca3e2.png)
接着解析<aop:aspect>下的declare-parents节点,通过DeclareParentsAdvisor作为beanClass加载,然后继续解析其他节点
![](https://img-blog.csdnimg.cn/img_convert/6179f4664866ee6acbded6e718c6b373.png)
在获取到节点后,遍历循环,解析其下的Advice类型的节点,通过调用isAdviceNode()判断遍历到的当前节点是否为Advice类型的节点
isAdviceNode()
判断是否为Advice节点
![](https://img-blog.csdnimg.cn/img_convert/f2027469ba40946c119cf3da517f055c.png)
如上图中方法上面的注释,Advice类型的节点有5个:
{@code before}
{@code after}
{@code after-returning}
{@code after-throwing}
{@code around}
与上面任何一个类型形同返回值即为true
解析成功则继续向下执行
![](https://img-blog.csdnimg.cn/img_convert/1f2c54025bfe92c8b3fec7392cb05465.png)
parseAdvisor()
![](https://img-blog.csdnimg.cn/img_convert/346935ff8edaef93295834b2ce8146d1.png)
方法parseAdvisor()先生成了methodDefinition(解析advice中的"method"属性,并包装为MethodLocatingFactoryBean对象 )、aspectFactoryDef(关联aspectName,包装为SimpleBeanFactoryAwareAspectInstanceFactory对象)这两个RootBeanDefinition对象,并依次为他俩赋值
![](https://img-blog.csdnimg.cn/img_convert/f30af756c13c99be2379095f9fdb75d1.png)
随后解析pointcut属性,将上面👆两个对象传入了方法createAdviceDefinition()中,包装为AspectJMethodBeforeAdvice对象返回并赋值给名为adviceDef的AbstractBeanDefinition对象
![](https://img-blog.csdnimg.cn/img_convert/62da715596d0b6155f4c52cb05329943.png)
最后将这个对象包装为名为advisorDefinition的RootBeanDefinition对象并为相关的属性赋值
![](https://img-blog.csdnimg.cn/img_convert/893f3982a261d9b58574ee692fdad452.png)
最后完成注册,就可以在parseContext对象的readerContext -> reader -> registry -> beanDefinitionMap属性中看到这个AspectJPointcutAdvisor对象叻(AspectJPointcutAdvisor#0)
![](https://img-blog.csdnimg.cn/img_convert/452688a1cdb9d46213f02dcaafa9288b.png)
那么问题来了:这些生成的RootBeanDefinition对象有什么区别吗,他们具体都是哪些类呢?
我们先来详细介绍下createAdviceDefinition()这个方法
createAdviceDefinition()
进入方法createAdviceDefinition()
![](https://img-blog.csdnimg.cn/img_convert/1a4dd546b08e3dc90ecb0d29bcc6291c.png)
首先根据adviceElement节点通过调用getAdviceClass()方法分析出是什么类型的Advice,获取到一个adviceDefinition对象
getAdviceClass()
这个方法其实与刚刚介绍过的isAdviceNode()判断的类型是完全一致的
![](https://img-blog.csdnimg.cn/img_convert/939aba87c8d995d944fd6253bd33f88c.png)
继续给刚刚获取到的adviceDefinition对象设置属性值
设置aspectName属性和declarationOrder属性
设置returning、throwing、arg-name这3个属性(先判断,有则设置)
设置构造函数的入参变量
Method
AspectJExpressionPointcut
AspectInstanceFactory
然后解析<point-cut>节点
![](https://img-blog.csdnimg.cn/img_convert/af90f17ac9955e594380f56fbf093903.png)
parsePointcutProperty()
![](https://img-blog.csdnimg.cn/img_convert/962a7fbce2939fc0c3286faf307ceaf5.png)
至此,方法createAdviceDefinition()执行结束,返回一个AbstractBeanDefinition类型的对象adviceDef。我们也来回答下介绍方法前的问题:这些生成的RootBeanDefinition对象具体都是哪些类呢?
![](https://img-blog.csdnimg.cn/img_convert/bd865cd93ac0411772d3005ad822cb8d.png)
methodDefinition:MethodLocatingFactoryBean
aspectFactoryDef:SimpleBeanFactoryAwareAspectInstanceFactory
adviceDef:AspectJMethodBeforeAdvice
adviceDefinition:AspectJPointcutAdvisor
回到方法parseAspect()中,将当前解析过的beanDefinition(advisorDefinition)添加进集合beanDefinitions中
![](https://img-blog.csdnimg.cn/img_convert/bb0d6fd97e8ba4526ebbec33a0a82d99.png)
接着进入下一轮循环♻️,继续解析列表中的节点
第二次循环执行完成在parseContext对象的readerContext -> reader -> registry -> beanDefinitionMap属性中又多了一个AspectJPointcutAdvisor对象(AspectJPointcutAdvisor#1),嘿嘿没错每完成一次循环就会多一个~~0、1、2……递增
![](https://img-blog.csdnimg.cn/img_convert/194f2908e9ff015f17228c0a89912743.png)
这些类外部都是AspectJPointcutAdvisor对象,用后缀#1、#2、#3……来区分,但是内部真正的通知类型Advisor是不一样的
循环结束后,返回到parse()方法中,由于我在XML配置文件(如下图)中加了两个aspect标签🏷️,所以childElts里有两个Element,于是会再按上面👆得大致流程再执行一遍
![](https://img-blog.csdnimg.cn/img_convert/5d88360ead349eb9ed9d4cbd3e58a1b9.png)
全部遍历完成后一路返回
其实吧,说到底BeanDefinition的解析过程( loadBeanDefinitions()),也就是配置文件的加载过程,毕竟都是Bean嘛^ ^