intellij-idea - IDEA 10.5.2 Aspectj 编译器 - 无法确定缺少类型 org.springframework.transaction.interceptor.TransactionAspectSupport 的父类(super class)

Question

尝试制作具有 Spring 方面的模块给了我:

无法确定缺少类型 org.springframework.transaction.interceptor.TransactionAspectSupport 的父类(super class)

在其他模块中工作，这个是怎么回事？缺少部门？

/S

Answer 1

不幸的是，这是使用 AspectJ 开发时不时发生的错误。

通常，在任何 Java 应用程序的类路径中，都有一些“死”类，即在某个 jar 中存在但从未使用过的类。

这些类通常也错过了它们的依赖关系。例如，Velocity(仅举一个例子，但大多数库都这样做)附带了连接许多日志记录工具的类，如 log4j、java 日志记录等。如果你想使用其中之一，你还需要包含它的依赖项(比如log4j.jar)，否则如果不使用，则无法添加该依赖项。

使用库时这本身不是问题，因为永远不会加载这些类。但是，当您使用 AspectJ 时，情况会发生一些变化。

假设你有一个像这样的切入点:

execution(int MyClass+.getSomething())

虽然这个切入点看起来非常具体，但它说的是“MyClass 的任何子类中名为 getSomething 的方法”。这意味着要知道某个类是否满足切入点，AspectJ 必须在编织时检查所有父类(super class)。

但是如果 AspectJ 试图在上面提到的“死类”上这样做会发生什么？它将搜索父类(super class)并失败，导致该类未使用且不满足其依赖关系。

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

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

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

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

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

在这种情况下，要责备的不是 AspectJ，而是包含死类的库，这些死类可以(并且应该)放在单独的模块中。许多库不这样做是为了避免“模块扩散”(例如，每个库应该为每个日志记录系统发布单个模块等等..)，这是一个很好的论点，但可以通过最近的模块管理轻松更好地解决系统(如 Maven、Ivy 等)，而不是将单个 jar 文件与大量具有未满足的依赖关系的类打包，然后在文档中说明您需要该依赖关系来加载该类。