Is my syntax for exclusion incorrect though? It doesn't seem to be working. I added:
<weaver options="-Xlint:ignore"> <!-- due to a bug in the AspectJ LTW, exclude any precompiled @Aspect classes from being a weave destination --> <exclude within="(@Aspect *..*)" /> <dump within="org.webapp.sso..*" beforeandafter="true"/> </weaver> But I still see the aspect being rewritten (and reverted) in the _ajdump folder. However, if i explicitly set the exclude to the full package name: <exclude within="org.webapp.sso..*" /> it works fine. Is my exclusion syntax by Annotation name incorrect? Do I need to specify a fully-qualified annotation name (ie: <within="(@org.aspectj.lang.annotation.Aspect *..*")/> )? Thanks, Eric On Thu, Jun 14, 2018 at 11:21 AM Andy Clement <[email protected]> wrote: > I added a bug yesterday > https://bugs.eclipse.org/bugs/show_bug.cgi?id=535877 with my minimal test > code in. Basically annotation style just hasn't got equal test coverage > with code style so we are going to hit things like this occasionally. > Excluding via @Aspect annotation is quite a clever workaround :) > > Andy > > On 13 June 2018 at 19:02, Eric B <[email protected]> wrote: > >> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
