Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] How to get more context information in adviceexecution() pointcut

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​


Back to the top