adviceexecution() has long needed some love, but I don't think it is used
very frequently hence it hasn't received that love.
1) When capturing adviceexecution(), sometimes thisJoinPoint.getArgs()
> yields
> a) { JoinPoint.StaticPart }
> for before() or after() advice,
> b) { AroundClosure, JoinPoint.StaticPart }
> for some around() advice,
> c) { AroundClosure }
> for other around() advice.
>
> I wonder why sometimes it is 1b, at opther times 1c. I think maybe
> 1b could be the result for nested around() advice, but I am not sure.
>
That would be embodied in the implementation unfortunately and it should
be better specified. I can imagine the behavior changes depending on
elements like whether the advice was expressed in annotation style or code
style - since they both support around advice differently. I'd take a bug
to better specify that but I'm not sure when I'll get to fixing it given
adviceexecution() usage.
>
> 2) I was kind of disappointed because on one hand I could get the
> information mentioned in 1 via tjp.getArgs(), but on the other hand
> was unable to bind it to parameters via args(). Does it make sense
> to change/improve that?
>
I do think adviceexecution() should allow some proper arg binding, yes. It
just is a little more complicated than regular args binding because the
signature of the advice is adjusted with extra arguments as required by the
advice implementation - this should probably all be hidden as an internal
detail.
>
> 3) When capturing adviceexecution(), I want to have a defined way of
> getting access to the joinpoint targeted by the underlying advice,
> so I can decide what to do in my advice, e.g. based on the method
> call/execution that was just captured. Is that possible or can
> AspectJ be enhanced to make it possible?
>
My gut reaction is that it seems reasonable.
>
> 4) While I found an undocumented way of calling proceed() in the
> captured advice without actually ececuting the advice itself (which
> is a way of dynamically deactivating/circumventing advice execution,
> but still calling the original application code targeted by the
> advice), I found no documented one. How stable is this way (cf.
> sample code on StackOverflow)? Can it be documented or exposed via
> JoinPoint API?
>
It may break with annotation style. It'll be stable in that no changes
have been made in that area for a while and none are planned but as it
isn't documented explicitly, it could be changed to address some issue down
the line. Firming up what is possible through API/documentation and having
it then 'fixed' is not unreasonable.
>
> 5) I also had to use AroundClosure.getState() for my stunt in 4, but
> the method is also undocumented. It seems to yield an obect array
> the first element of which seems to be the captured advice's target,
> the remaining elements seem to be the underlying method's
> parameters, regardless of whether they are bound via args() or not.
> Could this be documented or exposed to the API more clearly?
>
Could be, but I'd need to spend time refreshing my memory about that whole
area of the code.
>
> 6) I wish there was a way to restrict adviceexecution() by being able
> to specify which advice to capture, e.g. using a syntax like
> adviceexecution(execution(* foo.bar.MyClass.myMethod(..))). This
> might be a real big feature request, but I am asking anyway. :-)
>
This needs some thought, I wouldn't like to rush into what we do here.
Sounds like a bunch of work, yes. The other issues you bring up are much
smaller in scope to address I think.
cheers,
Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
