美文网首页
Spring AOP造成的@Controller注册失败

Spring AOP造成的@Controller注册失败

作者: 啊冬啊冬 | 来源:发表于2018-01-07 11:49 被阅读0次

昨天在重构项目时 ,抽取了Controller的公共方法到AbstractController中, 调整了原有Controller的路径 (包名) . 然后启动时发现几乎所有移动过包的Controller都失效了.

主要对象

  • ControllerLogInterceptor : aop拦截器 ,拦截目标路径下所有Controller
@Pointcut("execution(public * com.eddy..*.*Controller.*(..))")
public void handleController() {
}
  • AppController : 一个接口
public interface AppController {
    String getAppName();
}
  • AbstractController : 抽象的Controller ,包含一些公用方法 ;实现了AppController接口
@Slf4j
public abstract class AbstractController implements AppController {
    @Autowired
    protected HttpSession session;

    @Override
    public String getAppName() {
        return OSC_APPNAME;
    }
}
  • ContactController : 业务逻辑的Controller
@RestController
@RequestMapping("/eddy/contact")
public class ContactController extends AbstractOSCController {
...
}

原因分析

  • 因为是移动路径过后出现的 ,首先考虑路径影响
    • 使用的SpringBoot ,全注解配置的Controller ,路径并不会影响Bean的解析
    • 同路径下某一Controller可用 ,该Controller没有继承AbstractController ,继承了另一个类
  • 考虑AbstractController的影响
    • 改变路径前也是使用继承Controller的做法 ,没有出现问题
    • 这个类也在AOP的匹配范围内
  • 修改了AbstractController->AbstractAction ,依旧无效
    • AOP主要是代理原有Bean ,Abstract不会生成Spring Bean ,不会产生作用
  • 终极大招 ,源码断点:
    • 打印Debug Log : ContactController注册为Bean ,但没有扫描到mapping路径
    • 断点查看Spring如何扫描Controller并添加mapping的

RequestMapping

通过日志 ,找到扫描Mapping的目标类RequestMappingHandlerMapping (父对象AbstractHandlerMethodMapping#initHandlerMethods方法)

//AbstractHandlerMethodMapping.class
protected void initHandlerMethods() {
        if (logger.isDebugEnabled()) {
            logger.debug("Looking for request mappings in application context: " + getApplicationContext());
        }
        String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ?
                BeanFactoryUtils.beanNamesForTypeIncludingAncestors(getApplicationContext(), Object.class) :
                getApplicationContext().getBeanNamesForType(Object.class));

        for (String beanName : beanNames) {
            if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
                Class<?> beanType = null;
                try {
                    beanType = getApplicationContext().getType(beanName);
                }
                catch (Throwable ex) {
                    // An unresolvable bean type, probably from a lazy bean - let's ignore it.
                    if (logger.isDebugEnabled()) {
                        logger.debug("Could not resolve target class for bean with name '" + beanName + "'", ex);
                    }
                }
                if (beanType != null && isHandler(beanType)) {
                    detectHandlerMethods(beanName);
                }
            }
        }
        handlerMethodsInitialized(getHandlerMethods());
    }

可以看到 ,通过循环已加载的Bean ,然后通过相应Handler (这里是RequestMappingHandler) 判断是否应该处理.

//RequestMappingHandlerMapping.class
@Override
protected boolean isHandler(Class<?> beanType) {
    //判断对应class类是否 有Controller注解或继承自Controller注解 (RestController) 
        return (AnnotatedElementUtils.hasAnnotation(beanType, Controller.class) ||
                AnnotatedElementUtils.hasAnnotation(beanType, RequestMapping.class));
    }

这里断点调试后 ,发现ContactController直接跳过 ,它没有@Controller注解!!!! 但代码里确实进行了配置 ,在经过多次重编译过后 ... 发现ContactController对应Bean的classType是 com.sun.Proxy...

也就是说SpringAOP代理将这个Bean本有的信息抹除了 ,所以我修改了SpringAOP的匹配路径 ,果然Controller可用了.

但是AOP部分的代码也很重要 ,我不希望丢掉.同时我发现

  • 单一的Controller(无继承关系) 和 AOP 工作的很好
  • 继承自其他类的Controller也工作的很好
    那么 ,Spring的AOP应该是不会破坏Bean的类型判断的 : 他们的类型都是 com.eddy.ContactController$Spring..Cglib...这样的 ,是能够通过SpringMVC的检查的

结论

最后的不同就在于那个简单的接口...

  • Spring默认使用JDK ,对接口进行动态代理 : ContactController extends AbstractController implement AppController ,所以将与接口有关的类都代理成了Proxy .
  • 而继承自单一类/没有接口的 ,使用cglib代理 ,就不存在这个问题 ,他依旧保留了原有class的信息.

增加配置 spring.aop.proxy-target-class=true ,默认统一使用cglib即可

相关文章

网友评论

      本文标题:Spring AOP造成的@Controller注册失败

      本文链接:https://www.haomeiwen.com/subject/ngepnxtx.html