Re: [aspectj-users] How to resolve real execution signature for call joi

[Andy Clement <andrew.clement@xxxxxxxxx>]

I had a further thought about this problem whilst out on a run, I can imagine (although I haven't coded it up) something around and if() clause and using reflection with <target>.class.getDeclaredMethod(<thisJoinPoint stuff in here>) (and walking up the hierarchy) to check where the method is actually declared.  Won't do much for the performance though :)

> As for Signature.getDeclaringTypeName(), the acceptance criteria do not seem to involve dynamic method resolution, only static code analysis (what is the target's declared type?). Would it be possible to enhance that method, add a toggle or similarly named method for dynamic resolution?

Currently that information is built based solely on the invoke instruction (static info), we're not actually looking at what is on the stack so are at the mercy of what the compiler decided to do. It is feasible to add a similar named method but isn't that just the same as asking thisJoinPoint.getTarget().getClass() (at least for non static methods)?

cheers,

Andy

On 22 May 2014 16:06, Alexander Kriegisch <alexander@xxxxxxxxxxxxxx> wrote:

(Argh, I accidentally sent this one to early, next try. I am sorry.)


An afterthought: As for Signature.getDeclaringTypeName(), the acceptance criteria do not seem to involve dynamic method resolution, only static code analysis (what is the target's declared type?). Would it be possible to enhance that method, add a toggle or similarly named method for dynamic resolution?



Alexander Kriegisch schrieb am 23.05.2014 00:55:

> Okay, so you had the same thoughts ('if' pointcut and stacktrace check) as I
> and also the same results. We would need something like a sneek peek towards
> method resolution which happens just an instant later, but not quite at the
> call site.
>
> BTW, this was one of my experimental pointcuts:
>
> pointcut jdkType() :
> if(thisJoinPointStaticPart.getSignature().getDeclaringTypeName().startsWith("java."));
>
> But for the reasons I mentioned on StackOverflow this does not (and cannot)
> work reliably for two out of four cases.
>
> Thank you anyway :-)
> --
> Alexander Kriegisch
> http://scrum-master.de
>
>
> Andy Clement schrieb am 23.05.2014 00:48:
>
>> I can't immediately think of a way to do that. Even if using an if() clause on
>> the point cut to insert a runtime test, that test can't tell whose method is
>> running on the object you have (whether it is a local one or an inherited
>> one). You can't even inspect the stack trace in the advice (which would be
>> crude anyway) because the advice invocation is made at the call site before
>> you enter the method in question.
>>
>> Incidentally I am probably going to be hanging around on stack overflow more
>> these days so anyone posting questions here, feel free to start posting there,
>> I will see them :)
>>
>>
>> On 22 May 2014 00:59, Alexander Kriegisch <Alexander@xxxxxxxxxxxxxx
>> <mailto:Alexander@xxxxxxxxxxxxxx> > wrote:
>>> On StackOverflow I saw an interesting question. Even though I (user
>>> kriegaex) have answered it as good as I could at
>>> http://stackoverflow.com/questions/23791760/aspectj-separating-native-library-calls-from-application-calls/23799457#23799457
>>> <http://stackoverflow.com/questions/23791760/aspectj-separating-native-library-calls-from-application-calls/23799457#23799457>
>>> ,
>>> I am still wondering if there might be a way to find out which method a
>>> call really resolves to later in all of the four cases mentioned there,
>>> because in general a call joinpoint's signature is not necessarily equal
>>> to what gets executed later.
>>>
>>> I don't know if anyone can answer that, but my best guess would be Andy
>>> Clement (as usual). ;-)
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users