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 <[email protected]
> <mailto:[email protected]> > 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
