Community
Participate
Working Groups
See attached failing testCase.
Created attachment 43675 [details] Patch to tests module to add failing test case
testcase committed. Possibly a case of us being too lenient and should error when the type is missing rather than ignoring it.
Created attachment 43752 [details] Patch with 2 more test cases that build on the already committed first patch The most important thing to notice here is that even with the required type on the inpath the weaver still fails to resolve it. In a larger project this leads to a work-around of including the inpath entries on the classpath, which just can't be right.
I'd sure like to see a fix for this one in 1.5.2: it seems wrong to have to include a library entry in both classpath and inpath to allow resolving types. Surely this one should be fixed...
of course it needs fixing ... but it's one of those bugs that's always been there. Shame it wasn't raised as the two separate problems - one is easier than the other and may have made it into 1.5.2. but oh well. Problems: 1. Three cant find type messages are being ignored in the first of the testcases, thats the one I'm looking at. One of them relates to trying to calculate the pointcut residue for the match that occurs on the field set in the Sample.main() method (the residue is for the cflow). I am currently tempted to promote this particular cantfindtype to an unconditional error - once we get into this state we have matched a pointcut and are going to apply advice, we are then having problems calculating the residue and we can't go back and change our minds about the match (no mechanism). Other options seem to be working out at match time whether we know everything we'll need to create the residue - that sounds messy. 2. Does seem bizarre that inpath/aspectpath and available for type resolution - I have a fix for this but need to test it a little more.
ok - i followed up on my 'alternative' solution to (1) and have implemented it. if we cannot match because of a missing type, we give out a warning to indicate that is exactly what is happening. This is not a cant find type message, it is a new message that indicates a match couldnt be determined at a particular join point because we didn't know about a type. the message includes the type and the locations of the join point and the pointcut. Unable to determine match at this join point because the type 'Event' cannot be found By not matching, we don't fail miserably creating the residue and then blow up with a verify error. Silently ignoring the joinpoint with no message would have you climbing the walls in frustration trying to work out why there was no match. Note I have only fixed it for the cflow case here, there are probably other cases too. These are all indicative of having a weaver that was never intended to run with half a type system - making cantfindtype configurable causes all sorts of unexpected things to happen in the weaver. I would rather make cantFindType an error and resolve all cases where we are looking for too many types.
all fixes in. i'm nervous about the path change thing for some reason ... but all the tests are OK with it so I cant think why it will go wrong...
See also bug #145693 for more about removing Xlint cantFindType: allowing use of runtime tests while avoiding possible errors.
i think you mean bug 149322 where we are looking at whats possible for more flexible residue - if it can be determined to be safe.
Thanks for the correction Andy: that's what I meant. I forgot I had copied this bug # after copying the referenced one.
reopening to ensure I review this case when thinking about the new residue stuff - if I can work it out for other pcuts, we might be able to do something here, but this was a complex case (isnt cflow always...)
worth looking at in the 1.6.0 timeframe?
mentioning this bug on the other report as something to re-read and then closing this one.
