Skip to content
Advertisement

How to force AspectJ search from test directory in src directory of project using compile weaving?

Actually, it will be more complex question. I want use AspectJ only in test purpose. Have found suggestion to use if() JointPoint and some static boolean field. Also, first I start using aspect as inner static class of my base test method. After some experiments I replaced it to own class, but actually don’t got the result, that I want. So, I just create some test project. Maven pom.xml:

JavaScript

Classes: A:

JavaScript

B:

JavaScript

test class:

JavaScript

Aspect class

JavaScript

Main class:

JavaScript

And I got result after running test and main method:

  • changeValue() -> You have been hacked!
  • changeValueInA() -> classes.B
  • main(String[] args) -> classes.B

Second result dont feet for me… So after some experiments and removing test scope for AspectJ dependencies, removing if() JointPoint (we can’t use test classes from src) and placing Aspect class in src I got the result:

  • changeValue() -> You have been hacked!
  • changeValueInA() -> You have been hacked!
  • main(String[] args) -> You have been hacked!

Lust result dont feet to me too. And I really don’t want to use aspect for all project. After that I just tried to use some Load-Time weaving with configuration for maven surefire plugin:

JavaScript

And I got result, that I want:

  • changeValue() -> You have been hacked!
  • changeValueInA() -> You have been hacked!
  • main(String[] args) -> classes.B

So, where the question after thousands of these letters?) Questions are:

  1. Can I get this result with compile weaving and without using AspectJ classLoader?
  2. As I have performance restrictions in real project – how can AspectJ classLoader affect performance of non-test environment in this case?
  3. In case of load-time weaving that I describe – all classes of the project will recompile by AspectJ? Only test? How recompiling work in load-time?

I will greatfull for this answers!

Advertisement

Answer

You have several problems in your code:

  • You set useAspect = true before each test, but never reset to false after a test ends. This would bleed context out into other tests where you want the aspect inactive. You should clean that up.

  • The aspect has an if() pointcut depending on a static method in a test class. The test class is unavailable during application runtime under normal circumstances. The static field and its accessor methods (if any) should be in the aspect class itself.

    JavaScript
    JavaScript
  • Probably, your aspect is defined in src/test/java instead of src/main/java, which explains why it is only compiled into test classes and not into application classes. But the latter is what you expect, if a method call from one application class to another should be intercepted. Therefore, you need to move the aspect to the main sources and make aspectjrt have a compile scope, not a test scope.

But in this case where the aspect is supposed to only affect tests, I would recommend to not use compile-time weaving (CTW), because it would mean that the application always needs the AspectJ runtime on its class path (see above), even if the aspect is inactive. CTW only makes sense if at least sometimes during application runtime the aspect is meant to be active, too. Even then, it is debatable if load-time weaving (LTW) might not be the better solution, e.g. if it is a rarely used debugging aspect. CTW is ideal for production aspects. In this case, it seems to be fairly clear that LTW using the Java agent is the right approach. Like you said, you do not even need the ugly static field and the if() pointcut.

User contributions licensed under: CC BY-SA
1 People found this is helpful
Advertisement