Spring AOP不拦截从对象内部调用的方法原因

简介:   拦截器的实现原理很简单,就是动态代理,实现AOP机制。当外部调用被拦截bean的拦截方法时,可以选择在拦截之前或者之后等条件执行拦截方法之外的逻辑,比如特殊权限验证,参数修正等操作。   但是最近在项目中要在一个事务中跨数据源进行操作。

  拦截器的实现原理很简单,就是动态代理,实现AOP机制。当外部调用被拦截bean的拦截方法时,可以选择在拦截之前或者之后等条件执行拦截方法之外的逻辑,比如特殊权限验证,参数修正等操作。

  但是最近在项目中要在一个事务中跨数据源进行操作。数据库跨源就不在这里说了,可以自行百度。

  这里出现的问题就是,如果我们要拦截某个类的多个方法,且在该类的方法中使用this调用要拦截的方法时会导致拦截失败。

  这样说有点抽象,看一个代码:

package com.intsmaze.before;

public class AopDemo 
{

    /**
     * controller层调用的逻辑service方法,该方法内部调用分别访问不同数据库的service方法
     */
    public void findInforAll()
    {
        this.findDataBaseA();
        this.findDataBaseB();
    }
    /**
     * 这里我们就查询A数据库的某张表好了
     */
    public void findDataBaseA()
    {
        
    }
    /**
     *  这里我们就查询B数据库的某张表好了
     */
    public void findDataBaseB()
    {
        
    }

}

然后我们使用spring的aop写一个进行切入的类,该类主要就是在执行findDataBaseA和findDataBaseB前执行某些代码来告知后面的查询操作查询数据库的地址。

@Aspect
public class AuthAspect
{
    // 匹配com.intsmaze.before包下AopDemo 类的
    // 所有方法的执行作为切入点
    @Before("execution(* com.intsmaze.before.AopDemo .*(..))")
    public void authority()
    {
        System.out.println("模拟执行权限检查");
    }
}

接下来我就以比喻进行说明了,明白我的比喻的前提你要知道动态代理是什么,打个不恰当的比方吧,就是动态生成一个新的**类**(注意不是对象)。

这里我们可以这样看当执行findInforAll的时候,AOP监测到这个方法是要被拦截的,于是生成了一个代理类,就是一个新的类。

public class AopDemo+其他名称 
{

    /**
     * controller层调用的逻辑service方法,该方法内部调用分别访问不同数据库的service方法
     */
    public void findInforAll()
    {

  //---------------------------------------------------

    System.out.println("模拟执行权限检查");

     //---------------------------------------------------
        this.findDataBaseA();
        this.findDataBaseB();
    }
    /**
     * 这里我们就查询A数据库的某张表好了
     */
    public void findDataBaseA()
    {    
    }
    /**
     *  这里我们就查询B数据库的某张表好了
     */
    public void findDataBaseB()
    {       
    }

}

  这里我们可以看到,其实生成一个新的类,该类在findInforAll方法中第一行加上了AOP指定执行的方法。我们系统中调用的就是这个代理类的findInforAll方法,而该方法中的 this.findDataBaseA();this.findDataBaseB();是不会被AOP拦截的,因为AOP拦截的包名和类名很明显和代理类的不一样,所以这就是为什么内部调用的方法无法拦截的原因。不知道这样说,大家懂了没有。关于如何用JDK写动态代理,我会在放假时回顾以前笔记,在写出来。

  如何解决呢?我们开始想的时避免AOP切入的类中使用this内部调用,但是发现这样增加了代码结构的复杂度,本来只需要一个类,最后要使用两个类进行管理。太麻烦。

  然后考虑项目的进度,就使用把逻辑代码封装成工具方法进行调用。

 

在网上查资料有方法可以解决,没有测试。

http://blog.csdn.net/quzishen/article/details/5803721下面是主要思路。

在spring的源代码中通过一个增强对象的检查,控制了当前的内部调用是否使用代理来执行,这让人感到无奈。spring的作者们很隐晦的提出避免内部调用的方法。

我们可能会想,在外部调用两次beanA,第一次调用method1,第二次调用method2,这样做可以解决问题,但是这样的直接后果是我们的逻辑代码将变得紊乱,并非所有的场景下都可以通过这样的设计来完成。虽然这是spring官方推荐的避免内部调用的idea。

查看了相关资料,得到了一种方法,即在method1的内部,通过直接获取当前代理对象的方式然后通过代理对象调用method2,这样触发拦截。

看看代码:

public void method1(){  
        logger.error("1");  
          
        // 如果希望调用的内部方法也被拦截,那么必须用过上下文获取代理对象执行调用,而不能直接内部调用,否则无法拦截  
        if(null != AopContext.currentProxy()){  
            ((NorQuickNewsDAO)AopContext.currentProxy()).method2();  
        }else{  
            method2();  
        }         
    }  
      
    public void method2(){  
        logger.error("2");  
    }  

我们显示的调用了AopContext来获取当前代理对象,然后调用其方法,这样做还必须的一个步骤是将当前的代理暴露给线程使用,在配置文件中需要配置一个参数:

<property name="exposeProxy">  
            <value>true</value>  
        </property>  

它是ProxyConfig的一个参数,默认是false,如果不设置这个参数,那么上述java代码将无法获取当前线程中的代理对象。

这种方法可以成功触发拦截,但是也带来了其他问题,比如代码的织入,我们的代码将变得复杂而且晦涩,而且严格要求系统针对于当前的bean必须配置拦截器,否则会因为找不到拦截器而抛出异常。

这样做有什么负面影响?对事务的影响,对安全的影响,现在不得而知,还需要逐步去测试以尝试。

作者: intsmaze(刘洋)
老铁,你的--->推荐,--->关注,--->评论--->是我继续写作的动力。
微信公众号号:Apache技术研究院
由于博主能力有限,文中可能存在描述不正确,欢迎指正、补充!
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
1天前
|
Java Spring
【JavaEE进阶】 Spring AOP源码简单剖析
【JavaEE进阶】 Spring AOP源码简单剖析
|
1天前
|
Java Spring
【JavaEE进阶】 Spring AOP详解
【JavaEE进阶】 Spring AOP详解
|
1天前
|
数据采集 Java 程序员
【JavaEE进阶】 Spring AOP快速上手
【JavaEE进阶】 Spring AOP快速上手
|
7天前
|
Java Spring
|
7天前
|
存储 Java 数据库
Spring的使用-Bean对象的储存和获取/Bea对象的作用域与生命周期
Spring的使用-Bean对象的储存和获取/Bea对象的作用域与生命周期
|
7天前
|
Java Spring
|
21天前
|
Java 应用服务中间件 Maven
SpringBoot 项目瘦身指南
SpringBoot 项目瘦身指南
71 0
|
21天前
|
缓存 安全 Java
Spring Boot 面试题及答案整理,最新面试题
Spring Boot 面试题及答案整理,最新面试题
156 0
|
21天前
|
存储 JSON Java
SpringBoot集成AOP实现每个接口请求参数和返回参数并记录每个接口请求时间
SpringBoot集成AOP实现每个接口请求参数和返回参数并记录每个接口请求时间
58 2