Re: [aspectj-users] Strange classloader interaction when weaving with as

[Andy Clement <andrew.clement@xxxxxxxxx>]

Hi Frank,

I am currently investigating an issue with problematic declare
parents(mixins are implemented using the same strategy - I presume you
are talking about @DeclareMixin when you say mixin). This is under
https://bugs.eclipse.org/bugs/show_bug.cgi?id=302460 - there it
manifests as a compiler crash though, rather than silently doing
something wrong.  It is possible your issue and that issue are
related.

Just wish I could recreate either of the scenarios (yours or the one
in the bug), that would help immensely.

My current thoughts are that it relates to the more extensive use of
references to cache results in 1.6.8, and one particular one isn't
getting cleared at the right time.

Feel free to raise a new bug (in case it isn't related to the one I'm
looking into) or attach your findings to the existing one.

cheers,
Andy

On 24 February 2010 06:55, Frank Pavageau <frank.pavageau@xxxxxxxxx> wrote:
> 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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>