On 21/04/2009 16:41, Andy Clement wrote:
around call() advice tried to call a non-existent method.
what was the method?
That's a good question... I'm not working there any more.. finished a
few hours ago :) They're converts to AspectJ though.
It turns out that not all weaving activity is reported in weaveinfo
messages, as, in this case, the around call() expected to see the method
added to the target class.
Yes, some activities are performed on classfiles that do not get
reported in weaveinfo messages. The 'other end' of a cflow, the
privileged accessors created to make private fields visible outside of
a type - there are many many examples.
The weaveinfo messages are intended to relate to what the user was
doing with the syntax, and not to describe incidental changes - I mean
javac doesn't tell you when it adds a this$0 field or a secondary
constructor to a private inner class so that it is visible to the
containing class... sometimes magic just happens to support what the
user was doing ;)
Agree. I was just thinking of enhancing debug. Weaveinfo is about the
pointcuts, not the "under the hood" as you say.
Nothing is different (or at least nothing should be different) between
ltw and compile time weaving - apart from what is accessible for
weaving of course.
Yes. That's an interesting one. What I got was a call() advice that
was able to weave the call site, but not create the other bits needed.
What happens if that call had been into the JDK classes, and I was
doing it at compile time? That's what I'm puzzled by.
If you want to add further diagnostics, then I would certainly
consider them different from regular weaveinfo messages but really
when do you need to see them? In this case it sounds like a bug in
that something was allowed to happen that left the system inconsistent
(a method did not get added where expected) - and really that
shouldn't happen and whatever the cause was should be reported
earlier.
Ok. Perhaps my <exclude> should have triggered an alarm as there
was weaving required on that class.
(I think we have an open enhancement request to add these for the
other end of the cflow, but not for any of the others).
ok.
|
