在做springboot和shiro集成时,在度娘的多篇博文上相关DefaultAdvisorAutoProxyCreator有下图的描述,但实际测试时将usePrefix和proxyTargetClass二者任意一值设为true都可以解决无法映射请求的问题,此文即是基于此的拓展,有兴趣的童鞋可以在测试项目中进行测试。
要搞明白为这两个配置能够解决这个问题,可以先从DefaultAdvisorAutoProxyCreator开始看起,从类名上我们很容易得知这是spring自动代理创建器之一。该类可以对通知器进行过滤。
源码注释中表明,通过设置usePrefix值为true,类将仅在通知器bean名称为advisorBeanNamePrefix+.时生效。
而proxyTargetClass则配置了代理时是否时基于类代理。
由前面两点可以猜测
猜测不一定是正确的,并且由于二者都可以解决这个问题,还需要探求二者之间的关联。
当aop与权限注解共存时,不对DefaultAdvisorAutoProxyCreator进行任何配置并跟踪请求,部分执行链如下:
// {}表示同上
.
├── DispatcherServlet.doService
│ ├── DispatcherServlet.doDispatch
│ ├── DispatcherServlet.getHandler
│ ├── AbstractHandlerMapping.getHandler
│ ├── RequestMappingInfoHandlerMapping.getHandlerInternal
│ └── AbstractHandlerMethodMapping.lookupHandlerMethod
之所以跟踪这个请求,是由于在doDispatch方法中的HandlerExecutionChain类型变量是spring由容器中取得的实际处理请求的对象。
以下是测试控制器的部分代码
@RestController
public class IndexController {
@GetMapping
@RequiresPermissions("admin")
public String empty() {
return "hello";
}
}
在AbstractHandlerMethodMapping.lookupHandlerMethod中,可以看到此处从一个映射注册表中的两个hashMap对象中为请求获取最合适的处理方法,而在映射注册表中根本不存在我们的自定义控制器,由此得知问题的根源在于映射注册表中控制器的缺失。
在AbstractHandlerMethodMapping类中对类变量mappingRegistry进行查找,可以找到registerHandlerMethod方法,用于向注册表中注册处理方法。
而该方法的调用在detectHandlerMethods方法中,通过对该方法断点调试(启动时)并向上查找堆栈信息,我们可以得到这样一条调用链:
.
├── AbstractAutowireCapableBeanFactory.invokeInitMethods
│ ├── RequestMappingHandlerMapping.afterPropertiesSet
│ ├── AbstractHandlerMethodMapping.afterPropertiesSet
│ ├── AbstractHandlerMethodMapping.initHandlerMethods
│ ├── AbstractHandlerMethodMapping.processCandidateBean
│ └── AbstractHandlerMethodMapping.detectHandlerMethods
RequestMappingHandlerMapping是springboot WebMvcAutoConfiguration中预定义的,自动初始化的bean,用于处理被RequestMapping注解标记的方法。
而由于该类父类实现了InitializingBean接口,bean初始化完毕时会调用afterPropertiesSet方法,由调用链可以看出,映射注册表的初始化即是由这个逻辑促成的。跟踪正常映射的请求可以验证这一点:
AbstractHandlerMethodMapping.processCandidateBean方法中可以找到类能否被注册进映射注册表的逻辑:
spring从应用上下文中获取根据名称获取对应bean的类对象并根据类对象中是否含有Controller和RequestMapping注解来判断是否注册。
通过调试可以看到加入权限异常映射的bean,在容器中取到的类对象是代理对象,下面是几种情况取到的类对象:
可以看到前者取到的对象是由jdk动态代理的,而后两者取到的对象都是由cglib代理的。
由以上情况又引申出了三个问题:
这里涉及到调用链:
.
├── AnnotatedElementUtils.hasAnnotation
│ ├── TypeMappedAnnotations.isPresent
│ ├── TypeMappedAnnotations.scan
│ ├── AnnotationsScanner.scan
│ ├── AnnotationsScanner.scan
│ ├── AnnotationsScanner.process
│ ├── AnnotationsScanner.processClass
| └── AnnotationsScanner.processClassHierarchy
在AnnotationsScanner.processClassHierarchy中可以看到spring首先判断类对象上是否存在注解,如果不存在则递归查找该类对象父类,所有的接口和内部类。
/**
* 按层次执行类查找
*
* @param context 需要寻找的注解
* @param aggregateIndex
* @param source 类对象
* @param processor 注解处理器
* @param classFilter 类过滤(判断是否要忽略某些类查找)
* @param includeInterfaces 是否包含接口
* @param includeEnclosing 是否包含匿名内部类
* @param
* @return 匹配成功返回true 否则返回false或者null
*/
private static
try {
R result = processor.doWithAggregate(context, aggregateIndex[0]);
if (result != null) {
return result;
}
// 是否仅有普通的java注解
if (hasPlainJavaAnnotationsOnly(source)) {
return null;
}
// 判断类本身是否存在注解
Annotation[] annotatiOns= getDeclaredAnnotations(context, source, classFilter, false);
result = processor.doWithAnnotations(context, aggregateIndex[0], source, annotations);
if (result != null) {
return result;
}
aggregateIndex[0]++;
// 如果存在实现接口则遍历接口执行查找 判断接口上是否存在该注解
if (includeInterfaces) {
for (Class> interfaceType : source.getInterfaces()) {
R interfacesResult = processClassHierarchy(context, aggregateIndex,
interfaceType, processor, classFilter, true, includeEnclosing);
if (interfacesResult != null) {
return interfacesResult;
}
}
}
// 向上查找所有父类
Class> superclass = source.getSuperclass();
if (superclass != Object.class && superclass != null) {
R superclassResult = processClassHierarchy(context, aggregateIndex,
superclass, processor, classFilter, includeInterfaces, includeEnclosing);
if (superclassResult != null) {
return superclassResult;
}
}
// 查找内部类
if (includeEnclosing) {
// Since merely attempting to load the enclosing class may result in
// automatic loading of sibling nested classes that in turn results
// in an exception such as NoClassDefFoundError, we wrap the following
// in its own dedicated try-catch block in order not to preemptively
// halt the annotation scanning process.
try {
Class> enclosingClass = source.getEnclosingClass();
if (enclosingClass != null) {
R enclosingResult = processClassHierarchy(context, aggregateIndex, enclosingClass, processor, classFilter, includeInterfaces, true);
if (enclosingResult != null) {
return enclosingResult;
}
}
}
catch (Throwable ex) {
AnnotationUtils.handleIntrospectionFailure(source, ex);
}
}
}
catch (Throwable ex) {
AnnotationUtils.handleIntrospectionFailure(source, ex);
}
return null;
}
在使用cglib代理的情况下,可以在父类中查找到原始类对象,并获取到注解。
而在jdk动态代理情况下获得的对象中无法从类的父子关系,接口实现,内部类中得到原始类对象,也就无法获得原始注解。
以上可以得知代理方式的变更会导致类无法注册入映射注册表,导致bean无法映射请求。
在上面的探究中对比两种代理类的实现接口还发现,获取到jdk动态代理类对象时似乎被二次代理了,其中的原因我们放到后面再探究。
要了解这个问题,需要对bean的创建过程进行跟踪:
.
├── AbstractAutowireCapableBeanFactory.doCreateBean
│ ├── {}.initializeBean
│ ├── {}.applyBeanPostProcessorsAfterInitialization
│ ├── AbstractAutoProxyCreator.postProcessAfterInitialization
│ ├── AbstractAutoProxyCreator.wrapIfNecessary
│ ├── {}.createProxy
│ ├── AnnotationsScanner.processClass
| └── AnnotationsScanner.processClassHierarchy
在bean初始化完成后将在AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization方法进行后置处理,spring从容器中获取所有的后置处理器即所有实现BeanPostProcessor接口的bean对bean进行后置处理,在这里可以找到DefaultAdvisorAutoProxyCreator
在跟踪DefaultAdvisorAutoProxyCreator之前,先跟踪AnnotationAwareAspectJAutoProxyCreator,以了解一个正常执行的代理流程。
AnnotationAwareAspectJAutoProxyCreator是spring aop工作的重要构建器,上文我们猜测异常bean可能被二次代理了,第一次代理便是来自spring aop的代理。
在AopAutoConfiguration可以看到在默认配置(且存在Advice类)下使用注解开启了Aspect J自动代理
在此注解存在的情况下AspectJAutoProxyRegistrar将工作,这里将进行AnnotationAwareAspectJAutoProxyCreator的注册工作:
.
├── AspectJAutoProxyRegistrar.registerBeanDefinitions
│ ├── AopConfigUtils.registerAspectJAnnotationAutoProxyCreatorIfNecessary
│ └── {}.registerOrEscalateApcAsRequired
可以看到此处为bean定义在注册表中指定了名称
并且在另一处自动配置中将proxyTargetClass值设为了true:
AbstractAutoProxyCreator.wrapIfNecessary可以跟踪到AnnotationAwareAspectJAutoProxyCreator的创建代理的工作流程:
/**
* 按需包装(代理)bean
*
* @param bean bean
* @param beanName bean名称
* @param cacheKey 缓存key 用以标记该bean是否需要被通知
* @return 包装(代理)后的bean
*/
protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
return bean;
}
// this.advisedBeans在postProcessBeforeInstantiation即前置操作中初始化过一次
// 这里是跳过已经预先知道不需要被通知的bean
if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
return bean;
}
// 在bean的前置处理时其实已经做过类似的判断
// isInfrastructureClass是判断是否为aop的基础设施类 诸如Advice,Pointcut,Advisor等
// shouldSkip是由bean名称判断是否为原始示例 如果为是(名称为bean类名+.ORIGINAL)则跳过
if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}
// Create proxy if we have advice.
// 获取所有的通知bean 存在则进行代理操作
Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
if (specificInterceptors != DO_NOT_PROXY) {
this.advisedBeans.put(cacheKey, Boolean.TRUE);
// 创建代理
Object proxy = createProxy(
bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
this.proxyTypes.put(cacheKey, proxy.getClass());
return proxy;
}
// 不存在通知类 则标记为不需要通知
this.advisedBeans.put(cacheKey, Boolean.FALSE);
return bean;
}
创建代理时用到了创建器本身的proxyTargetClass属性用以判断是否基于类代理,这里前面提到,在自动配置时就已经将该bean proxyTargetClass属性默认设置为true,因此由该类创建的代理对象默认都是基于cglib代理的:
如果在配置中配置默认代理方式不基于类(spring.aop.proxy-target-class =false),但类不存在合适的代理接口,spring仍可能选择cglib代理:
/**
* 评估接口是否适合代理
*
* @param beanClass bean类对象
* @param proxyFactory 代理工厂
*/
protected void evaluateProxyInterfaces(Class> beanClass, ProxyFactory proxyFactory) {
// 获取所有实现接口
Class>[] targetInterfaces = ClassUtils.getAllInterfacesForClass(beanClass, getProxyClassLoader());
boolean hasReasOnableProxyInterface= false;
for (Class> ifc : targetInterfaces) {
// isConfigurationCallbackInterface判断接口是否配置回调接口 例如:InitializingBean,Closeable等
// isInternalLanguageInterface判断接口是否内部语言接口 例如:GroovyObject,cglib代理工厂接口等
if (!isConfigurationCallbackInterface(ifc) && !isInternalLanguageInterface(ifc) &&
ifc.getMethods().length > 0) {
hasReasOnableProxyInterface= true;
break;
}
}
if (hasReasonableProxyInterface) {
// Must allow for introductions; can't just set interfaces to the target's interfaces only.
for (Class> ifc : targetInterfaces) {
proxyFactory.addInterface(ifc);
}
} else {
// 没有合适的实现接口则也设置为true
proxyFactory.setProxyTargetClass(true);
}
}
这一点也解释了为何不引入spring aop的情况下权限注解可用,有兴趣的童鞋可以尝试下载代码进行设置跟踪。这里只讲结论:
DefaultAdvisorAutoProxyCreator和AnnotationAwareAspectJAutoProxyCreator的工作过程基本类似。从以上工作过程中其实可以大概了解(实际也是如此),DefaultAdvisorAutoProxyCreator异常工作时,对bean再次进行了代理行为,由于该类的proxyTargetClass的默认值为false,且获取的代理对象被判断为适合接口代理,因此采用了jdk动态代理,从bean实例上来看就是被二次代理了。
另外需要提及的是当仅proxyTargetClass为true时虽然进行了两次代理,代理类上获取的直接父类还是原始类(而不是父类的父类才是原始类)。详见:
.
├── AbstractAutoProxyCreator.wrapIfNecessary
│ ├── {}.createProxy
│ ├── ProxyFactory.getProxy
| └── CglibAopProxy.getProxy
这里的问题其实应该是,为什么设置usePrefix为true时不进行代理,事实上usePrefix为true时,DefaultAdvisorAutoProxyCreator是不工作的。
这里需要从getAdvicesAndAdvisorsForBean方法中进行跟踪,因为当设置usePrefix为true时,该方法取到的通知器是空的。
.
├── AbstractAutoProxyCreator.wrapIfNecessary
│ ├── {}.getAdvicesAndAdvisorsForBean
│ ├── AbstractAdvisorAutoProxyCreator.findEligibleAdvisors
│ ├── {}.findCandidateAdvisors
│ └── BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans
在BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans中,从容器中取得的通知器是否要最终返回用于代理,存在isEligibleBean判断。
前面都是和构建器父层抽象类打交道,到这里终于和DefaultAdvisorAutoProxyCreator本身打上了交道。
这个判断最终使用了DefaultAdvisorAutoProxyCreator.isEligibleAdvisorBean的返回结果。
在DefaultAdvisorAutoProxyCreator.isEligibleAdvisorBean中得知,当usePrefix为false时该方法总是返回true,而当usePrefix为true时需要判断bean名称是否以类属性advisorBeanNamePrefix+.开头判断如何返回。
当只定义了usePrefix为true而未定义advisorBeanNamePrefix时,大部分情况下bean名称是无法匹配的,因此通知器无法返回,也就不会执行具体的代理行为。而定义usePrefix为false时代理行为总是执行的。
再次提出之前的两条猜测:
现在看,两个猜测都是部分正确的,并且以上的探究对其进行了拓展,在探究的过程中我们得知,冲突的本质在于是否使用jdk动态代理,只要bean没有被jdk动态代理,这个映射问题就不会存在。下面是各种场景下的运行情况:
最后总结usePrefix,proxyTargetClass解决的问题:
以上为本文全部内容,本文首发于Maples Blog