Community
Participate
Working Groups
The $ (dollar) symbol is a valid character for a type name e.g. generated Java proxies are called $Proxy0 and CGLIB generates proxies like com.foo.Name$$EnhancerByCGLIB$$12345 (see bug 117854). However the pattern matching fails so com.foo.* won't match the CGLIB proxy but com.foo..* will. This maybe because the $ characters are being converted to . (dot).
Created attachment 30860 [details] Testcase Shows aspect matching joinpoints in Test but not Test$$EnhancerByCGLIB$$12345
I'll look into this. As we discussed in the cafeteria, this is almost certainly because of our $->. conversion assuming inner types.
fix in tree, waiting on build.
Adrian - your fix for this introduced the 1.5 api isMemberClass() into the reflection based delegate. I've removed the api call but found I had to force the isNested() method that uses it to return 'true' (?!?!) in order for the tests to all pass. I'm surprised a default return value of 'true' (indicating everything is nested...) is what is required - can you take a look??
Build is through, but I still want Adrian to take a look ... (see previous comment)
Doh - sorry about the 1.5 API.... but the rest of what you observed makes sense. The "splitNames" routine used to always convert $ -> ., even when it shouldn't. With the change, it only does this for a nested type. Turns out that many routes into the world create resolved types with $s in their names for nested types. It is also the case that all of the PointcutExpression tests that would have been failing for you use nested types exclusively. So defaulting to "false" would cause failure for nested types, and be different from our previous (99.99% correct) behaviour. Defaulting to true means that we will always do the conversion - which might cause trouble for reflection based resolved types under 1.4 or lower with genuine dollars in their names - but that's a pretty small set and there's not much we can do about it!
