[aspectj-users] Strange classloader interaction when weaving with aspec

[Frank Pavageau <frank.pavageau@xxxxxxxxx>]

Hi.

I have a weaving problem when using AspectJ 1.6.7 or 1.6.8 which
doesn't happen with 1.6.6, but cannot extract a test case for. If
someone has any suggestion for tracing the problem, maybe I'll be able
to report the bug properly.

I have a multi-module maven project :
 - in module1, I have an @Aspect which declares a mixin as well as
advices using the mixin interface, the pointcuts being on the
recipient of the mixin
 - in module2 which depends on module1, I have another @Aspect
declaring a pointcut on some module1 classes and an advice using this
pointcut

With AspectJ 1.6.6, everything works fine : module1 is built fine, and
when the aspect compilation happens in module2, the aspects from both
module1 and module2 are reweaved just fine on the module1 classes.

With AspectJ 1.6.7 or 1.6.8, however, the aspect compilation during
the build of module2 incorrectly reweaves the module1 aspect on the
module1 classes. More specifically, the weaved class does not
implement the mixin interface, resulting when running the unit tests
in a "java.lang.IncompatibleClassChangeError: Class XXX does not
implement the requested interface YYY", which I have confirmed by
decompiling the class.

The aspects are weaved in using aspect-maven-plugin, and this is where
it gets interesting. The plugin does not execute ajc externally, but
uses the embeddable compiler (Main class from aspectjtools), which
means it runs in the Maven JVM with all the plugins loaded. As it
happens, module2 is a war module, which means the maven-war-plugin is
loaded. However, if I change the module type to jar or simply run "mvn
clean test" instead of "mvn clean install" in module2, the
maven-war-plugin is not loaded and the problem disappears!

I don't know what exactly is loaded with the war plugin, but
apparently its presence in the maven classloader changes the behavior
of the AspectJ compiler. So, does anybody have any pointers on what to
do to trace this, since it seems to me to be an AspectJ bug? Logs to
activate, for example. Unless this directly rings a bell with an
AspectJ developer, related to the 1.6.6 / 1.6.7 evolutions.

I have tried trimming the project to produce a testcase, but there's
always some point where I remove a totally unrelated class and the
problem disappears... And of course, I cannot send my complete
project.

Thanks,
Frank