Community
Participate
Working Groups
Hi, when I try to translate an existing aspect into the annotation-based style (according the developers notebook) my example doesn't work any more: @Aspect("perthis(this(verwaltung.Person))") public class ArbeitszeitAspekt { // body: see at the end } Here the compiler says "can't do instanceof matching on patterns with wildcards". When I try @Aspect("perthis(this(Person))") ... I get no compiler message but it does not work (even if the aspect is also in the same package "verwaltung") - I have not the expected output (dead pointcut). @Aspect ... This works (but only as singleton and not an aspect for each Person object), so the rest of my aspect seems to be ok. Is this a bug (which I should report) or do I use the wrong syntax for the perthis statement? kind regards Oliver ==== here some additional info ====> Mmy original aspect where I want to stop the time of the Person.arbeite() execution: public aspect ArbeitszeitAspektOld perthis(this(verwaltung.Person)) { long start; long end; // void around(Person x) : execution(public void Person.arbeite()) && this(x) { start = System.currentTimeMillis(); proceed(x); end = System.currentTimeMillis(); System.out.println("*** Arbeitszeit " + x + ": " + new Date(start) + " - " + new Date(end)); } } And here the body of the aspect (just to complete the example) public class ArbeitszeitAspekt { long start; long end; // @Around("execution(public void verwaltung.Person.arbeite()) && this(x)") public void watchWorkingHours(ProceedingJoinPoint thisJoinPoint, Person x) { start = System.currentTimeMillis(); thisJoinPoint.proceed(new Object[] {x}); end = System.currentTimeMillis(); System.out.println("*** ARBEITSZEIT " + x + ": " + new Date(start) + " - " + new Date(end)); } }
Created attachment 26721 [details] the ArbeitszeitAspekt which causes the error
Created attachment 26722 [details] the Person class which is instrumented by ArbeitszeitAspekt
this has to be fixed for M4...
looks like an issue in pointcut matching the perthis(this(.....)) ends up in doing matching pretty much everywhere (f.e. target type field get / set), leading to an error (bug) in type pattern match internal which assumes a MathKind.Dynamic public FuzzyBoolean matchesInstanceof(ResolvedType type) { //XXX hack to let unmatched types just silently remain so if (maybeGetCleanName()/*Simple()*/ != null) return FuzzyBoolean.NO; type.getWorld().getMessageHandler().handleMessage( new Message("can't do instanceof matching on patterns with wildcards", IMessage.ERROR, null, getSourceLocation())); return FuzzyBoolean.NO; I think here we need CleanName and not SimpleName test. When done this way, the aspect is not any more bound - while it is for simpler clause like perthis(execution(....))
mhh changing to CleanName does not help as the stuff commented with ugly //XXX hack always returns NO hence the bypass changing to STATIC matching fix the stuff, but then we end up in rendering Bcel test for Literal.NO which interrupt with a BException "bad" I think there is an issue in the pointcut parsing there Adrian, can you have a look ? WildTypePattern.matchesInstanceof test will be committed in AtAjSyntaxTest.testPerClause (see testPerThis() as other tests are turned off).
I have an idea what's going on here. When a pointcut is parsed, all of the type patterns within it are "WildTypePatterns". It is only when the pointcut is resolved that these turn into ExactTypePatterns (and a whole bunch of additional checks are done). I'm betting that the perthis pointcut is being parsed but not resolved...
OK, have confirmed in debugger that the PerClauses read in from the annotation are indeed not being resolved. Now it just remains to find the appropriate point to drive the resolution logic...
2 issues there: Adrian spotted that the perClause pointcut was not resolve, which was leading to WildTypePattern not beeing narrowed to ExactTypePatterns Then we ended up in an issue where the ajc$Migth HasAspect interface for the matching type was not applied hence skipping the binding. It happens that the PerThisOrTargetPointcutVisitor that turns the perclause in a type pattern matching for the PerObjectInterfaceTypeMunger to apply is rather weak as it transform the perthis(this(someType)) in someType+ by using a toString() and a type parsing again. When $ stands in the type (inner class signature), we end up f.E. with Some$Type+ for a type pattern expression which is different from Some.Type+ as a user would write - hence the bug.
should be fine for this use case now
closing for next shipment
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.
