Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] writing around advice for an unknown method

Arvind Krishnaswamy schrieb:
> I have an urgent 'newbie' question and could not get the info from the docs 
> and forums upon a brief search. I am confused about the around advice and 
> calling proceed from within it.

> I want to write an 'around' advice for a random method call (e.g. the 
> pointcut call(* *(..)). For such pointcuts, I don't know about the matching 
> method call and its return type. For instance, the method might return 
> nothing (void) or a primitive or an object. How do I write the 'proceed' 
> statement in this case?


Hello Arvind,

the "proceed(..)" mirrors the signature of your around advice.
You can consider advice as being a java method, and the simple
check is that the around advice must be able to stand in place
of the proceed, which is like a method invocation.

Thus, if you're advising a pointcut which provides parameters,
then obviously your advice needs to accept compatible parameters
and so does the embedded proceed(..)
In your case, the pointcut doesn't provide arguments and thus
your around advice has no parameters. Thus, the proceed is
no-arg.

Regarding the return value, I'm not completely sure. I know that
there's some autoboxing in place, thus you'll e.g. get an
java.lang.Integer, even if the advised entity returns an int.
If I recall correct (please just try it out!), if the proceed()
*might* return a value, then you'll get an object, which can
be null (and will be if there isn't a return value).

hope that helps
Hermann V.


PS: there is an not-so obvious consequence of this parameter
handling with around: If your pointcut picks up the *target*
of a call and exposes this target as a *parameter*, then you're
indeed able to *exchange* the target object with another object
instance of compatible type within the around advice. In this
special case, according to the reasoning given above, you have
to supply either the original or an exchanged call target as an
*parameter* to proceed. That's an incredibly useful feature,
both for injecting testcode as well as for abstracting services.






Back to the top