By default if you weave aspects on top of aspects then we use a model where
we revert to the original class file before the first set of aspects was
applied and apply all of them (the original aspects plus the new ones) at
the same time to ensure consistency. This behavior is configurable using
the overweaving option (
http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html ). I'm
not sure whether I suspect that though.

Is the aspect with the aspectOf() missing part of the CTW or the LTW?  Was
the LTW library built with javac or ajc? Building annotation style aspects
with javac can be done but it will mean they are 'unfinished' and don't
have aspectOf/hasAspect - those will be added later when a weaver sees them.
Is everything loaded by the same class loader?  If you were LTWing some
code but the aspects were loaded by a class loader not subject to weaving
then this might happen. But then I know you are showing decompiled output
that contains the missing methods.

I don't have an obvious answer but there are no known issues with mixing
things up like this, really shouldn't be a race condition. You could turn
on verbose output for LTW and see if the things you are expecting to get
modified *are* modified.

cheers,
Andy

On 11 June 2018 at 14:07, Eric B <ebenza...@gmail.com> wrote:

> I have a multi-module EAR application that is comprised of:
> - EJB jar
> - WAR
> - aspect library
> - supporting libs
>
> My AspectJ library is designed to be used as LTW; it has pointcuts
> targetting some of the 3rd party libs.
>
> I have now created a new jar module in which I would like to use CTW.  I
> have configured by build properly, and can see that all my jars in my new
> module have been properly woven during the build process.  However, when I
> include the new lib in my ear, I get the following error message:
>
> 16:43:39,689 ERROR [io.undertow.request] (default task-35) UT005023:
> Exception handling request to /webapp/updateUserAccount.do:
> java.lang.NoSuchMethodError: org.webapp.sso.keycloak.aspect.
> ClientErrorExceptionHandler.aspectOf()Lorg/webapp/sso/keycloak/aspect/
> ClientErrorExceptionHandler;
>         at org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl.updateUserPassword(AccountAdministrationImpl.
> java:1)
>         at org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl$Proxy$_$$_WeldClientProxy.updateUserPassword(Unknown
> Source)
>
>
>
> However, when I look at the decompiled code for
> ClientErrorExceptionHandler, I see it contains the aspectOf() method:
>
>
> @Aspect
> public class ClientErrorExceptionHandler
> {
>   public static ClientErrorExceptionHandler aspectOf()
>   {
>     if (ajc$perSingletonInstance == null) {
>       throw new 
> NoAspectBoundException("org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler",
> ajc$initFailureCause);
>     }
>     return ajc$perSingletonInstance;
>   }
>
>   public static boolean hasAspect()
>   {
>     return ajc$perSingletonInstance != null;
>   }
> ...
> ...
>
> So I'm not sure what is happening.  Can this be some form of a race
> condition between the Load Time weaver and the Compile Time code?  My LTW
> aspects are in a completely different jar file, with their own aop.xml that
> have nothing to do with my current package.
>
> I've also double checked that my new jar does not contain an aop.xml.
>
> How can I further debug this issue?
>
> Thanks,
>
> Eric
>
>
>
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Reply via email to