I have worked around the issue by adding it to an <exclude> in the <weaver>
tag, but I was a bit surprised I had to do that.  Reading your explanation
now, makes it a little more clear.

I tend to prefer annotation style aspects, simply because, in general, most
other people who need to maintain the codebase are not very versed in
aspect programming, and I don't want to introduce yet another syntax to the
code.  I guess for now, I'll just leave it in the <exclude> although it
might be more interesting to see if I can exclude it by type instead of by
class name.  I'm guessing I could simply exclude it by the @Aspect
annotation?

<exclude within="(@Aspect *..*)" />

Do I need to file a bug for this?

Thanks,

Eric


On Wed, Jun 13, 2018 at 4:08 PM, Andy Clement <andrew.clem...@gmail.com>
wrote:

> I did just recreate this, I suspect one reason is hasn’t shown up before
> is because we don’t typically use annotation style aspects in test cases.
> If your aspect is annotation style and not code style you will see the
> aspectOf() issue.  I originally wrote mine as code style (the CTW aspect) -
> everything fine. The minute I switched it to annotation style, exactly the
> same problem as you.
>
> Andy
>
>
> On Jun 13, 2018, at 12:43 PM, Andy Clement <andrew.clem...@gmail.com>
> wrote:
>
> Let me try to interpret this from what I remember:
>
>
> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
> info processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> must be defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).
>
>
>
> That suggests to me the weaver has encountered a type that *might* be a
> candidate for modification (ClientErrorExceptionHandler) - per
> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
> ‘weaving
> XXX’ doesn’t mean XXX is being modified, it just means the weaver is
> looking at it (terrible message, needs improvement) - and since you have
> weave info on then if something about it matched a pointcut you’d see a
> weave info message.
>
> Looking at the reweavable state is fine but maybe it isn’t currently smart
> enough to make the distinction that it doesn’t matter that the
> ClientErrorExceptionHandler isn’t on the aspect path because none of the
> new aspects are matching it - I honestly can’t recall how that situation is
> handled and would need to dig through the code. I’m surprised if that is
> the case, but it could be. The fact that there is an error is probably why
> the resultant system doesn’t work, once the error happens all bets are off.
>
> What I’d try for experiments:
> - stick ClientErrorExceptionHandler on the aspect path. This means it can
> be found by reweaving processing - is it all good now?
> - include an exclude in the weaver XML for that
> ClientErrorExceptionHandler - if excluding it entirely is the reweavable
> state ignored?
> - run with overweaving on - should avoid reweavable processing.
>
> I’m not saying there isn’t a problem here just collecting more data points
> and looking at possible workarounds,
>
> cheers,
> Andy
>
>
> On Jun 12, 2018, at 8:42 AM, Eric B <ebenza...@gmail.com> wrote:
>
> Thanks for the link Andy.  I read through the overweaving description, and
> I agree that it doesn't sound like it applies.
>
> The aspect missing the aspectOf() is part of the CTW.  All Aspects are
> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW
> aspects, everything runs smoothly; all I have done was add in an additional
> jar with CTW aspect/classes.  The LTW still seems to be working, although I
> would have to do more in-depth tests to validate that they are still being
> triggered where they need to be.
>
> My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly
> not entirely sure if they are all using the same classloader.  Given that
> the CTW classes are in the ear/lib folder, as are the LTW aspects (both
> jars are found in ear/lib), I suspect that they both are in the same
> classloader, but I'm really not sure.  I know that WF has done a lot of
> work, separating classloaders by module (so that the different modules in
> an EAR each have different classloaders), but I suspect there must be a
> common one for all classes in the ear/lib folder.
>
> All that being said, I enabled the aspectj dumper with the beforeandafter
> option:
>
> <aspectj>
> <aspects>
> <aspect name="common.security.logger.LoginLoggerAspect" />
> <aspect name="common.security.logger.PasswordResetLoggerAspect" />
> <aspect name="common.security.logger.SessionLoggerAspect" />
> <aspect name="common.security.logger.AccessDeniedLoggerAspect" />
> </aspects>
> <weaver options="-Xlint:ignore -verbose -showWeaveInfo -debug">
> <dump within="org.webapp.sso..*" beforeandafter="true"/>
> </weaver>
> </aspectj>
>
>
> and interestingly enough, in the _before folder, I see the problematic
> Aspect class properly woven, but in the after class, it reappears in its
> original non-woven form.  As the LTW overweaver has reverted the class.
> And even more interesting, I cannot seem to find the pointcut in my LTW
> aspects that would have picked out this class in the first place.  Most of
> my pointcuts are "execution" pointcuts pointing to completely different
> pkgs.  There are a couple of "call" pointcuts as well as one cflow(), but
> in all cases, none should be picking out this Aspect.
>
> If I check the server.log file, I see the following being logged, which I
> don't particularly understand:
>
> 2018-06-12 10:21:51,708 ERROR [stderr]   [ModuleClassLoader@2d758982]
> info processing reweavable type 
> org.webapp.sso.keycloak.administration.SessionAdministrationImpl:
> org\webapp.sso\keycloak\administration\SessionAdministrationImpl.java
> 2018-06-12 10:21:51,711 ERROR [stderr]   [ModuleClassLoader@2d758982]
> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> woven into 'org.webapp.sso.keycloak.administration.SessionAdministrationImpl'
> must be defined to the weaver (p
> laced on the aspectpath, or defined in an aop.xml file if using LTW).
> 2018-06-12 10:21:51,802 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.administration.UserServiceImpl'
> 2018-06-12 10:21:51,834 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.administration.
> SessionAdministration'
> 2018-06-12 10:21:51,861 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl'
> 2018-06-12 10:21:51,877 ERROR [stderr]   [ModuleClassLoader@2d758982]
> info processing reweavable type 
> org.webapp.sso.keycloak.administration.AccountAdministrationImpl:
> org\webapp.sso\keycloak\administration\AccountAdministrationImpl.java
> 2018-06-12 10:21:51,877 ERROR [stderr]   [ModuleClassLoader@2d758982]
> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> woven into 'org.webapp.sso.keycloak.administration.AccountAdministrationImpl'
> must be defined to the weaver (p
> laced on the aspectpath, or defined in an aop.xml file if using LTW).
> 2018-06-12 10:21:51,896 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.administration.UserService'
> 2018-06-12 10:21:51,932 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.config.KeycloakConfigBean'
> 2018-06-12 10:21:51,968 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.keycloak.admin.client.Keycloak'
> 2018-06-12 10:21:51,973 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.keycloak.admin.client.resource.UserResource'
> 2018-06-12 10:21:51,975 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.administration.
> AccountAdministration'
> 2018-06-12 10:21:52,011 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.administration.UserService'
> 2018-06-12 10:21:52,026 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,046 ERROR [stderr]   [ModuleClassLoader@2d758982]
> info processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,046 ERROR [stderr]   [ModuleClassLoader@2d758982]
> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> must be defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).
> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
> info processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> must be defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).
>
>
>
> For some reason, the LTW thinks it should be weaving my
> ClientErrorExceptionHandler (the aspect) even though it isn't part of my
> aop.xml?  Is there a way to enable pointcut matching/debugging so I can see
> which pointcut is triggering the reweaving/rewriting of this @Aspect class?
>
> Thanks,
>
> Eric
>
>
>
> On Mon, Jun 11, 2018 at 6:29 PM Andy Clement <andrew.clem...@gmail.com>
> wrote:
>
>> 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
>
> _______________________________________________
> 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
>
_______________________________________________
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