IDEA 10.5.2 Aspectj编译器 - 无法确定缺失类型的超类org.springframework.transaction.interceptor.TransactionAspectSupport

Question

尝试使用spring方面创建一个模块让我:

无法确定缺失类型的超类org.springframework.transaction.interceptor.TransactionAspectSupport

在其他模块中工作,这个是什么？缺少dep？

/ S

Answer 1

不幸的是,这是使用AspectJ进行开发时不时出现的错误.

通常,在任何java应用程序的类路径中,都有一些"死"类,即某些jar内部的类,但从未使用过.

这些类通常也会错过它们的依赖关系.例如,Velocity(名称为1,但大多数库都这样做)附带了用于桥接许多日志记录工具的类,如log4j,java日志记录等.如果要使用其中一个,还需要包含其依赖项(如log4j.jar),否则如果不使用它,则无法添加该依赖项.

使用库时,这本身不是问题,因为永远不会加载这些类.但是,当您使用AspectJ时,事情会有所改变.

假设您有一个切入点:

execution(int MyClass+.getSomething())

虽然这个切入点看起来非常具体,但它表示"在MyClass的任何子类中名为getSomething的方法".这意味着要知道某个类是否符合切入点,AspectJ必须在编织时检查所有超类.

但是,如果AspectJ试图像上面提到的"死亡阶级"那样做,会发生什么？它将搜索超类并失败,因为该类未被使用且它的依赖性不满足.

我通常会指示AspectJ在这种情况下仅警告我,而不是引发阻塞错误,导致9次中有10次这发生在死代码上,并且可以安全地忽略.

另一种方法是找出哪个切入点导致AspectJ检查该类并尝试重写它以使范围更严格.然而,这并不总是可行的.

一个肮脏但快速的黑客可能是写:

execution(... MyClass+ ....) && !this(org.springframework.....)

这通常是由AspectJ优化的,因此在尝试评估完整的执行切入点之前,!this(....)会失败.但它会将您的切入点与特定情况联系起来,因此仅对测试最后一次修补有用搜索更好的解决方案时运行的系统.

在这种情况下,应该责备的不是AspectJ,而是包含死类的库,它们可以(并且应该)放在单独的模块中.许多库不这样做是为了避免"模块扩散"(比如,每个库应该为每个日志记录系统发布单个模块等等),这是一个很好的论据,但是可以通过最近的模块管理轻松地解决系统(如Maven,Ivy等......)而不是打包带有大量具有未满足依赖性的类的单个jar文件,然后在文档中声明需要该依赖项来加载该类.

Answer 2

您需要添加spring-tx依赖项以清除此问题：

http://mvnrepository.com/artifact/org.springframework/spring-tx

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-tx</artifactId>
        <version>${spring.version}</version>
    </dependency>