Hi Andy. Your idea is more sophisticated and more powerful too, no doubt. Me being a Scrum/Agile guy, I would rather prefer to have a way to bind all arguments like I proposed in AJ soon than waiting for another couple of years for the "grand scheme" implementation. The ticket you pointed to is from 2008 and I know you don't have a lot of free cycles. So I guess if your idea was easy to implement, you might have done so already. IMO a small improvement now is better than a big one which never happens. But of course, if you are ready to tackle the feature you just suggested, it would be great too. :) Or maybe the two features are the same order of magnitude with regard to complexity, even though that would surprise me.
Cheers -- Alexander Kriegisch https://scrum-master.de Andy Clement schrieb am 06.09.2020 01:07 (GMT +07:00): > > > I'm not totally surprised casting the joinpoint didn't work, I just hoped > :) I think we can probably get that to work. On the face of it your > proposal sounds reasonable for binding args. However, I still find it very > ugly that you can't just get the parameters that met the pointcut > constraints and get rid of all that code that retests whether they are > annotated, which is why I pointed to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=233718 > > aspect X { > // Note this advice will match and run multiple times - once for each > param > void around(String paramToScrub): call(* *(..,@Scrubbed (String),..)) && > args(paramToScrub) { return proceed(scrubString(paramToScrub)); > } > // More optimal perhaps, less nesting, probably easier to implement > void around(org.aspectj.lang.MatchedArg[] args): call(* *(..@Scrubbed > (String),..)) && args(matchedArgs) { > for (MatchedArg arg:args) > > arg.setValue(scrubString(arg.getValue()); > return proceed(args); > } > } > > Andy > > > On Fri, 4 Sep 2020 at 18:44, Alexander Kriegisch <alexan...@kriegisch.name > <mailto:alexan...@kriegisch.name> > wrote: > >> Bug 233718 is not really what I was concerned about. >> >> Casting thisJoinPoint to ProceedingJoinPoint was an idea I also had >> before, but the subsequent proceed(args) call returns null. If you run >> this aspect in native syntax against the sample classes in my SO >> answer... >> >> package de.scrum_master.aspect; >> >> import java.lang.annotation.Annotation; >> import java.lang.reflect.Method; >> >> import org.aspectj.lang.ProceedingJoinPoint; >> import org.aspectj.lang.SoftException; >> import org.aspectj.lang.reflect.MethodSignature; >> >> import de.scrum_master.app.Scrubbed; >> >> public aspect StringScrubberAspect { >> Object around() : call(public * *(.., @de.scrum_master.app.Scrubbed >> (String), ..)) { >> Method method = ((MethodSignature) >> thisJoinPoint.getSignature()).getMethod(); >> Object[] args = thisJoinPoint.getArgs(); >> Annotation[][] parameterAnnotations = method.getParameterAnnotations(); >> for (int argIndex = 0; argIndex < args.length; argIndex++) { >> for (Annotation paramAnnotation : parameterAnnotations[argIndex]) { >> if (paramAnnotation instanceof Scrubbed) >> args[argIndex] = scrubString((String) args[argIndex]); >> } >> } >> try { >> System.out.println(thisJoinPoint instanceof ProceedingJoinPoint); >> Object result = ((ProceedingJoinPoint) thisJoinPoint).proceed(args); >> System.out.println(result); >> return result; >> } catch (Throwable t) { >> throw new SoftException(t); >> } >> } >> >> private String scrubString(String string) { >> return string.replaceAll("[Ee]", "#"); >> } >> } >> >> ... the console log will be: >> >> true >> null >> true >> null >> >> How about extending 'args()' functionality in order to allow binding to >> an Object[] parameter which does not occur anywhere in the pointcut >> literal, automatically binding the equivalent of JoinPoint.getArgs() to >> it and thus allowing to proceed with the same bound parameter in both >> native and @AspectJ syntax? That would be kind of elegant, probably >> manageable from the perspective of pointcut parsing because there is no >> really new syntax, and the functionality to proceed with an Object[] is >> already in the code base, which is why it works in @AspectJ syntax. >> >> -- >> Alexander Kriegisch >> https://scrum-master.de >> >> >> Andy Clement schrieb am 05.09.2020 02:05 (GMT +07:00): >> >> > I feel like there are some bugs that talk around this topic, but I >> > can't quite find the one I'm thinking of. I found >> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=233718 and >> it was >> > interesting to read what I was writing 12 years ago :) I feel like i >> > prototyped an improved arg matching system but I hit something >> > seriously complex before finishing, and wrote about it in bugzilla >> > somewhere... >> > >> > I don't think you are missing anything. Mixing the syntaxes should be >> > ok I think. Can you cast thisJoinPoint to a ProceedingJoinPoint in >> > AspectJ syntax around advice and use it? I can't quite remember. >> > >> > >> > On Thu, 3 Sep 2020 at 22:41, Alexander Kriegisch wrote: >> > >> >> Check this out: >> >> https://stackoverflow.com/a/63735393/1082681 >> >> >> >> Is there anything I have overlooked? If so, how would I do that in >> >> native syntax? If not, would it be hard to implement? >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org >> <mailto:aspectj-users@eclipse.org> >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
