Doug,
You might try using some Xlint option to
handle missing types, to see if the compiler gets any further. I wrote a blog
entry about this approach here: http://rbodkin.blogs.com/ron_bodkins_blog/2005/12/a_hidden_treasu.html
This might be the cause of your problem, although it might also be you’ve
hit a bug…
I would also suggest you try doing
something really simple like compiling a system.out.println tracing aspect on
method executions or declare warning on the same, just to see if you can get
the basic weaving working with the top link jar you are working on
From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of doug.gschwind@xxxxxxxxxxx
Sent: Tuesday, June 20, 2006 12:40
PM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Capturing
join points in third party products
Hello AspectJ subscribers,
I am attempting to introduce advice when certain method calls of a
third party product are invoked and obtain access to the value returned from
those certain methods. My interpretation of reading the AspectJ cookbook (first
edition) is that I should follow the instructions present in section 2.4,
Weaving aspects into Jars. My motive here is that the aspect I have introduced
to capture these method calls is giving me adviceDidNotMatch Xlint warnings at
compile time and I can see my intended advice NOT being hooked at runtime.
So, I figured this was due to the third party jar needing to be dealt
with in a different way than capturing method calls on one's own codebase.
Thus, section 2.4 suggests the use of -inpath at compile time to indicate the
.jar file to be dealt with. I was also going to try the -outjar option to
capture the results of that compilation and use that resulting .jar at runtime.
Has anyone faced this issue with AspectJ 1.5.1_a and dealt with it
differently and had success?