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
