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