[aspectj-users] Bug 435446 - ClassFormatError when targetting nested forEach lambda expressions

Hello, I hope it is not against this group's etiquette to link to a new Bugzilla ticket: https://bugs.eclipse.org/bugs/show_bug.cgi?id=435446 If anybody can comment on the problem here or on Bugzilla, thanks in advance. -- Alexander Kriegisch http://scrum-master.de smime.p7s Description:

[aspectj-users] How to resolve real execution signature for call joinpoint

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, I am still wondering if there might be a way to find

[aspectj-users] java.lang.UnsupportedClassVersionError

Hi, When i try to weave an application deployed in ibm WAS 6, server is generating ajcore files with following information. WAS version: 6 ASPECTJ version:1.7 java.lang.UnsupportedClassVersionError: (org/aspectj/weaver/loadtime/definition/DocumentParser) bad major version at offset=6

Re: [aspectj-users] java.lang.UnsupportedClassVersionError

Hi, with WAS 6 you are limited to Java 5 and I guess for AspectJ 1.7 you need at least Java 6. regards, Oliver Am 22.05.2014 um 15:30 schrieb Krishna Jasty krishna.ja...@tcs.com: Hi, When i try to weave an application deployed in ibm WAS 6, server is generating ajcore files with

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

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

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

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:

Re: [aspectj-users] Bug 435446 - ClassFormatError when targetting nested forEach lambda expressions

I'll take a look, I'd like to wrap up a few issues and get a 1.8.1 out very soon. Last week I updated the internals to bring in a slew of Java8 fixes from JDT core. cheers Andy On 22 May 2014 00:50, Alexander Kriegisch alexan...@kriegisch.name wrote: Hello, I hope it is not against this

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

An afterthought: As for Signature.getDeclaringTypeName(), the acceptance criteria do not seem to involve Am 23.05.2014 um 00:55 schrieb Alexander Kriegisch alexan...@kriegisch.name: Okay, so you had the same thoughts ('if' pointcut and stacktrace check) as I and also the same results.

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

(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

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

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