IDEA 10.5.2 Aspectj compiler - cannot define a superclass of an unfulfilled type org.springframework.transaction.interceptor.TransactionAspectSupport

Question

Trying to create a module with aspects of spring gives me:

cannot define superclass with missing type org.springframework.transaction.interceptor.TransactionAspectSupport

Works in other modules, what about this? Missing dep?

/ S

Answer 1

You need to add the spring -tx dependency to clear this:

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

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

Answer 2

this is, unfortunately, an error that occurs from time to time when developing with AspectJ.

Often there are some “dead” classes in the classpath of any java application, that is, classes that are inside some kind of jar but are never used.

These classes often also overlook their dependencies. For example, Velocity (to indicate one, but most libraries do this) comes with classes for combining many logging facilities such as log4j, java logging, etc. If you want to use one of them, you also need to include its dependency (for example, log4j.jar), otherwise, if you are not using it, you cannot add this dependency.

This is not a problem in itself when using the library, because these classes will never be loaded. However, when you use AspectJ, things change a bit.

Suppose you have a pointcut like:

 execution(int MyClass+.getSomething()) 

While this pointcut seems very specific, it says "a method called getSomething in any subclass of MyClass." This means that in order to know that a class meets or not a pointcut, AspectJ must check all superclasses during weaving.

But what happens if AspectJ tries to do this in a "dead class", as mentioned above? It will look for the superclass and fail because the class is not used and its dependencies are not executed.

Usually I instruct AspectJ only to warn me in this situation, instead of raising a lock error, they call 9 times out of 10, this happens in dead code and can be safely ignored.

Attempts to determine which pointcut calls AspectJ to test this class and try to rewrite it so that the scope is more strict. However, this is not always possible.

Dirty, but quick, hack one could write:

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

This is (usually) optimized by AspectJ, so it (....) crashes before trying to evaluate the complete point point of execution, but ties your pointcut to a specific situation, therefore it is only useful for testing the last second fix of the running system when searching for the best solution.

In this case, it is not AspectJ that is to blame, but libraries containing dead classes that can (and should) be placed in separate modules. Many libraries do not do this in order to avoid "distribution of modules" (for example, each library should produce separate modules for each logging system, etc.), which is a good argument, but can be easily and simply solved with recent module management ( e.g. Maven, Ivy, etc.) instead of packing individual jar files with many classes with unsatisfied dependencies, and then indicating in the documentation that you need this dependency to load this class.

Answer 3

Spring's AbstractTransactionAspect - considers spring's TransactionAspectSupport links -tx - do you have this in folders?

Answer 4

I just solved a similar problem by making maven clean.

The error message was almost the same, but was about my own classes. Therefore, I think that the answer from Simone Gianni should be correct, there were some incorrect classes that were created by the IDE for some reason, so just delete them, then everything should be fine.