Re: [aspectj-users] Getting the method arguments of a Pointcut using args

[Alexander Kriegisch]

> Yes an allArgs designator would be nice to have which would simplify
> the things. My workaround using the ThreadLocal is enough for now as
> it would unblock the use case but it was also nice to know the
> workaround only using AspectJ even though my code is in an application
> using Spring framework and unfortunately Spring doesn’t support
> percflow instantiation model.

Well, you asked on the AspectJ mailing list, I had no idea it was about
Spring AOP. But AspectJ can be used from within Spring instead of or in
combination with Spring AOP, as described in this Spring manual chapter:

https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-using-aspectj

> Regarding the designator I haven’t created any issue on Bugzilla and
> let the decision to be made by Andy Clement about the issue and its
> priority :)

Well, if you don't create the ticket it will surely be forgotten. If you
do create it, it will still be Andy to decide about it. But obviously it
is not so important for you because workarounds do exist in both AspectJ
and Spring AOP, even though they involve manual bookkeeping. So we can
close this issue. It was a nice discussion, talk to you next time.

-- 
Alexander Kriegisch
https://scrum-master.de

___
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

Re: [aspectj-users] Getting the method arguments of a Pointcut using args

[Sina Golesorkhi]

Thanks Alexander for the response. 

Yes an allArgs designator would be nice to have which would simplify the 
things. My workaround using the ThreadLocal is enough for now as it would 
unblock the use case but it was also nice to know the workaround only using 
AspectJ even though my code is in an application using Spring framework and 
unfortunately Spring doesn’t support percflow instantiation model  
.

Regarding the designator I haven’t created any issue on Bugzilla and let the 
decision to be made by Andy Clement about the issue and its priority :) 

Kind Regards
Sina 

> On Sep 8, 2019, at 4:56 AM, Alexander Kriegisch  
> wrote:
> 
> What you are implementing is called a wormhole pattern, only in your case you 
> want to generalise it with respect to the caller arguments. For that you 
> would need a hypothetical pointcut designator allArgs(myParameter) which does 
> not exist and which would bind the whole Object[] as produced by 
> Pointcut.getArgs() to a pointcut or advice parameter with a corresponding 
> type. I admit it would be nice to have. If you believe you need it and cannot 
> live with a workaround, feel free to create a Bugzilla ticket for it for 
> future consideration. I cannot speak for Andy Clement, so I have no idea if 
> he would consider implementing it or if he even has free cycles to do so.
> 
> As you said, you could use a singleton aspect with ThreadLocal variable in 
> order to achieve what you want. As an alternative, I want to show you how you 
> can do it with percflow instantiation. Which alternative you choose will 
> depend on how many aspect instances would have to be created in your case and 
> if that would become a problem or not. I recommend to just give it a try:
> 
>  
> package de.scrum_master.aspect;
> 
> import org.aspectj.lang.JoinPoint;
> import org.aspectj.lang.ProceedingJoinPoint;
> import org.aspectj.lang.annotation.Around;
> import org.aspectj.lang.annotation.Aspect;
> import org.aspectj.lang.annotation.Before;
> 
> import de.scrum_master.app.CallerAnnotation;
> 
> @Aspect("percflow(execution(* *(..)) && 
> @annotation(de.scrum_master.app.CallerAnnotation))")
> public class AnotherAspect {
>   private CallerAnnotation callerAnnotation;
>   private Object[] callerArgs;
> 
>   @Before("execution(* *(..)) && @annotation(callerAnnotation)")
>   public void executeCaller(JoinPoint joinPoint, CallerAnnotation 
> callerAnnotation) {
> this.callerAnnotation = callerAnnotation;
> callerArgs = joinPoint.getArgs();
>   }
> 
>   @Around("execution(public void callee(String, Integer))")
>   public Object executeCallee(ProceedingJoinPoint joinPoint) throws Throwable 
> {
> System.out.println(joinPoint);
> System.out.println("  Caller annotation: " + callerAnnotation);
> System.out.println("  Caller arguments:");
> for (Object arg : callerArgs)
>   System.out.println("" + arg);
> System.out.println("  Callee arguments:");
> for (Object arg : joinPoint.getArgs())
>   System.out.println("" + arg);
> return joinPoint.proceed();
>   }
> }
> 
> The console log for my previously posted sample code if you only replace the 
> aspect:
> 
> execution(void de.scrum_master.app.SampleClazz.callee(String, Integer))
>   Caller annotation: @de.scrum_master.app.CallerAnnotation(value="xyz")
>   Caller arguments:
> de.scrum_master.app.Foo@527740a2
> de.scrum_master.app.Bar@13a5fe33
>   Callee arguments:
> x
> 11
> execution(void de.scrum_master.app.SampleClazz.callee(String, Integer))
>   Caller annotation: @de.scrum_master.app.CallerAnnotation(value="abc")
>   Caller arguments:
> 22
>   Callee arguments:
> y
> 22
>  
> Kind regards
> -- 
> Alexander Kriegisch
> https://scrum-master.de 
>  
> Sina Golesorkhi schrieb am 07.09.2019 19:31:
> 
> Hi Alexander, 
>  
> Thanks for response. Please find my comments below.
> 
> On Sep 5, 2019, at 5:30 AM, Alexander Kriegisch  > wrote:
> Hi Sina.
> 
> Your request sounds a bit like ordering Mousse au Chocolat without chocolate 
> in a restaurant.
> 
> Interesting metaphor but I don’t see it being the case here :) 
> Your advice has two very specific Foo and Bar parameters, but the 
> corresponding pointcut should not bind them to method parameters. Where else 
> would they come from then? What is the problem anyway? Please give me a 
> reason for wishing to avoid making the pointcut specific to the method 
> signature, then maybe I can help you find a solution for your problem.
> 
>  
>  
> The idea is to be able to annotate a method to tag it so that you can define 
> an Aspect in which you extract some information from the annotation and the 
> annotated method, hence @CallerAnnotation * *(..)).  The reason that I’m 
> using * * (..) is because the I don’t want the Aspect to become aware of 
> signature