Hard to decide without digging in. Either Spring AOP not checking the data it asked to parse is empty after parsing a pointcut from it, or should the API be stronger so that parsing the Pointcut is expected to consume all data from a string and if it doesn’t it is an error thrown by AspectJ. I wonder if any AspectJ tests fail if the parser is made that little bit more strict.
Cheers, Andy > On Dec 10, 2018, at 7:33 PM, Alexander Kriegisch <alexan...@kriegisch.name> > wrote: > > Sorry for being curious and asking again, Andy. Do you qualify it as an > AspectJ or Spring AOP issue? > > > Cheers > -- > Alexander Kriegisch > https://scrum-master.de <https://scrum-master.de/> > > Alexander Kriegisch schrieb am 29.11.2018 11:58: > >> Hi Andy, >> >> I quickly tested it with the aspect compiled with javac and then loaded, >> finished and woven via LTW. I see an error message as expected: >> >> [AppClassLoader@18b4aac2] info AspectJ Weaver Version 1.9.1 built on Friday >> Apr 20, 2018 at 16:47:33 GMT >> [AppClassLoader@18b4aac2] info register classloader >> sun.misc.Launcher$AppClassLoader@18b4aac2 >> [AppClassLoader@18b4aac2] info using configuration >> /C:/Users/alexa/Documents/java-src/SO_AJ_53397837_Java/bin/META-INF/aop.xml >> [AppClassLoader@18b4aac2] info register aspect >> de.scrum_master.aspect.BogusPointCutAspect >> [AppClassLoader@18b4aac2] error at >> de\scrum_master\aspect\BogusPointCutAspect.java::0 Invalid pointcut >> 'execution(* *(..)))))) && !target(java.lang.String)': >> org.aspectj.weaver.patterns.ParserException: unexpected pointcut element: >> ')'@18:18 at position 18 >> Doing something >> So this rather seems to be a Spring AOP issue than one in AspectJ, even >> though Spring AOP uses AspectJ's pointcut fast-match and >> PatternParser.parsePointcut() turns the expression execution(* *(..)))))) && >> !target(java.lang.String) into the pointcut execution(* *(..)), see my >> attached screenshot from a debugging session in IntelliJ IDEA. So somehow >> AspectJ is part of the story again. I am unsure if a ticket should be >> created for Spring AOP because it somehow uses AspectJ in a wrong wrong way >> or rather for AspectJ because that is where the parsing happens. Maybe you >> do what you think is best by yourself. >> >> Regards >> -- >> Alexander Kriegisch >> https://scrum-master.de <https://scrum-master.de/> >> >> Andy Clement schrieb am 29.11.2018 02:24: >> >>> You know I feel like I've seen that before, and done the same debugging you >>> did. It may even be an open issue on Spring AOP. I don't mind a ticket to >>> make us a little more strict there. >>> >>> >>> >>> On Sun, 25 Nov 2018 at 01:53, Alexander Kriegisch <alexan...@kriegisch.name >>> <mailto:alexan...@kriegisch.name>> wrote: >>> I found something on SO, debugged a bit through the AspectJ source code and >>> saw that this happens: >>> >>> https://stackoverflow.com/a/53466329/1082681 >>> <https://stackoverflow.com/a/53466329/1082681> >>> >>> I tested with AspectJ 1.8.9 and have not verified whether it is the same in >>> 1.8.13 or 1.9.2. If so, do you think this is worth a Bugzilla ticket with >>> regard to the PatternParser class? > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users > <https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users
