从一个Aspectj织入失效问题的解决说起

互联网全栈架构

共 3731字,需浏览 8分钟

 ·

2021-12-28 22:30

问天、问地、查百度、搜谷歌,就是不想看官网 ~ ~

事出反常必有妖

组里兄弟领了个任务,维护一个common工具包,用于精简和规范组内编码的公共事项,其中一个功能是AOP拦截提供了基于Aspectj的自定义枚举AOP拦截jar包,但使用方使用时编织不进去,让帮瞅瞅。

这,应该不难才对呀,日志AOP不是经常写么? 很多实现方式的哇~

:为啥不搞个spring 组件包?不管你的切面在哪,Component 扫描不是无往不利么?
:不行,组内项目基本没有依托spring的,都是纯Java项目,不带任何框架~
:黑人问号~

:搞个动态代理?
:不好,使用方接入成本大,最好只加个注解,而且希望更节省性能
:黑人问号~
这是非得用AspectJ编译期编织了?

不管会不会,都得先支棱起来

解决问题是关键,为啥会出现使用方引了jar包却编织不生效的情况呢? 先复现下再说。

定义注解

先搞一个注解LogAnnotation , 供使用方标注需要拦截的方法,也给Aspectj提供切点:
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface LogAnnotation {
}

定义切面

来个简单的切面,以上述的自定义注解为切点,拦截所有标注了的方法,随便打个日志:
public class LogAspect {
    @Pointcut("@annotation(com.test.aop.LogAnnotation)")
    public void LogStartTimePointcut() {
    }

    @Around("LogStartTimePointcut()")
    public Object around(JoinPoint joinPoint) throws Throwable {
        System.out.println("进来了~");
        ProceedingJoinPoint pjp = (ProceedingJoinPoint)joinPoint;
        Object result = pjp.proceed();
        System.out.println("要出去了:" + result);
        return result;
    }
}

普通场景验证

先本系统来个Test类验证切面是否正确:
POM中引入aspectj-maven-plugin 打包插件
编译时,切面被正常的编织进方法中了~
说明正常场景下是没问题的,接下来,打包,发布,让第三方项目引用。

引用第三方切面实现AOP拦截

另起一个项目引入上述Jar包,随便找个方法,添加LogAnnotation注解:
public class ConsumerHookImpl implements ConsumerHook {
    @Override
    @LogAnnotation
    public boolean prepare(DTEngineRequest engineRequest) throws Exception {
        return true;
    }
}
在pom中添加了相同配置的aspectj-maven-plugin插件后进行编译,居然真的没有编织切面~ 好神奇~

排查和解决

问题不大,肯定是扫描范围和路径的问题,只要能找到把我们jar放在mvn编译默认范围内的方法,问题应该就解决了。
怎么办呢?上网一搜,一水的都在说用SpringComponentScan ~ 🌚
要是能用Spring, 还有这些破事么,没办法了,祭出法宝--官方网站!
aspectj-maven-plugin 官网
都不用仔细看,打眼一看,发现了什么~
如果AspectJ 连jar包中被编译过的类都可以重新编织切面,把我们的jar包引入默认环境,还不是手拿把掐?
按说明向aspectj-maven-plugin插件的配置中添加weaveDependencies(编织依赖)属性,填入我们的jar包。
再执行编译,居然,就真的,可以正常编织切面了~

刨根问底儿拦不住

weaveDependencies 配置怎么起作用

Aspectj 作为一个专业的、完备的切面解决方案,支持了编译时编织、运行时编织、编译后编织多种切面实现策略,上述的新增配置,其实属于编译后编织的功能。
对比下添加前后的编译日志:
aspectJ配置加载相关日志
编织过程相关日志
过滤出关键信息,可以看到,在添加了编织依赖包的配置之后,aspectj插件将我们的目标Jar 添加到了classpath下。切点和切面被纳入aspectj编译范围,因此可以生效。

Aspectj 怎么和 Maven 相结合

我们知道,Aspectj之所以可以在maven项目的编译阶段进行切面编织,是因为maven plugin的存在。
maven的生命周期
实际上,对于Maven来说,只是定义了一套抽象的生命周期,就像我们平时定义的模板方法,而要想每个方法真正为我们所用,则需要通过具体插件来对每个方法进行绑定。这里的方法,其实就是上图中的phase,也可以叫做目标。
摘自:segmentfault.com/a/1190000038973480
比如,我们最常用的maven-compiler-plugin,是用来编译Java代码的,而我们本文涉及到的插件aspectj-maven-plugin,则是用来编织Aspectj切面的。

Aspectj的编织原理

- 编译时织入

通过上述分析,可以知道,aspectj编译时织入,是在编译期,获取被切点标识的class源文件,并进行重构,将切面逻辑写入并重新生成class文件。
摘自:csdn woshimalingyi/article/details/73252013
这种编译时织入的方式,总的来说是最简单的。
但是,在很多时候,我们希望框架可以足够灵活,也希望切面组件和业务代码可以被独立开发,所以,更适合的编织时机,其实应该是在class被载入虚拟机时。

- Load-Time-Weaving Load时织入

既然对编织提出了更高的要求,那实现起来也必然更复杂。
Load-Time Weaving 官网介绍
JVM是一个相对封闭的容器,内部定义了一系列既定操作,比如类加载、解析、初始化等等。
但是,说封闭也并不是绝对的,他预留了很多的口子,供给容器的使用者在特殊场景下对JVM的内部实现进行干预。但是因为JVM的重要性,任何口子都需要通过代理Java agent 才能被干预。
针对类加载这个模块,JVM预留的口子叫做Java Instrumentation , 而Aspectj为了干预JVM而提供的Agent 则是aspectjweaver.jar
官网对load-time-weaving的说明
那么,具体怎么干预的呢?
public class Agent { 
     ...其他略
    /**
     * JSR-163 preMain Agent entry method
     * @param options
     * @param instrumentation
     */

    public static void premain(String options, Instrumentation instrumentation) {
        /* Handle duplicate agents */
        if (s_instrumentation != null) {
            return;
        }
        s_instrumentation = instrumentation;
        s_instrumentation.addTransformer(s_transformer);
    }
}
可以看到,最重要的一个类Agent,提供了一个premain方法,其注释关注下,JSR-xxx ,表示这是一个Java规范,是标准,只能这么写。
而方法入参中的Instrumentation,是JVM调用该方法时传入的,并且在方法内部,给其添加了一个字节码转换器
看到这里,应该就大概其明白其工作原理了。

吾日三省吾身

本篇文章从一个日常的小问题入手,将aspectj的编织问题、依赖的maven生命周期和切面编织时机及其实现原理进行了阐述。
其实这都不是重点,重点只有一个:遇到问题,看官网文档才是真正有效的解决之道~


推荐阅读:

常见消息中间件大 PK

为什么CTO不写代码,还这么牛逼?



互联网全栈架构

浏览 37
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报