Community
Participate
Working Groups
I encountered this problem while implementing the bean() PCD in Spring 2.5. In that context (but not in the regular AspectJ context), this is a pretty serious bug that is preventing the use of the bean() PCD in a reference pointcut. Note that when the same pointcut is used directly with advice (anonymous pointcut), all goes well. It seems PatternParser.parseReferencePointcut() called by parseSinglePointcut()) treats a custom poitncut in a similar way to this(), target(), @target() etc. and tries to validate the argument to such pointcut as a type. For a custom PCD that takes a non-type argument (for example, bean() that takes a name-pattern argument), it can't find a matching type and ends up throwing an exception. I will try to create a standalone test case. Meanwhile, the commented out portion in org.springframework.aop.aspectj.BeanNamePointcutAtAspectTests illustrates the problem.
Ramnivas - are you correctly setting your custom handlers on the pattern parser? Custom handlers are searched before we treat it as a reference pointcut? This fails for me: aspect X { pointcut p(): bean(foo*); before(): p() {} } until I register the bean handler with the pattern parser, something like: BeanDesignatorHandler b = new BeanDesignatorHandler(); Set s = new HashSet(); s.add(b); patternParser.setPointcutDesignatorHandlers(s,world); Then the custom handler is discovered at PatternParser.parseSinglePointcut() and we never make it to parseReferencePointcut() I'm not sure how to access that spring code (yet ;) - so can't see quite what you are doing. Perhaps you are setting it but a different pattern parser instance is eventually used? Let me know and I'll investigate further.
I am now able to debug the scenario. running testMatchBeanName. First time into the pointcutparser, we parse: execution(* set*(..)) && bean(testBean1) and this goes fine. Second time in we come in with testBean1SetAge() - as a reference pointcut. This parses ok initially, as a ReferencePointcut. Then we attempt resolution of it with pc = pc.resolve(resolutionScope); leading us to this call in ReferencePointcut.resolveBindings() ResolvedPointcutDefinition pointcutDef = searchType.findPointcut(name); After messing about in some overly complex iterator combining logic, we end up in: getDeclaredPointcuts() being called upon org.springframework.aop.aspectj.BeanNamePointcutAtAspectTests$CounterAspect Then down in the Java15ReflectionBasedReferenceTypeDelegate.getDeclaredPointcuts method we create a new parser of type InternalUseOnlyPointcutParser - this does not have the bean() extension defined and so we treat bean(foo) as a reference pointcut rather than one of our new pointcuts. The problem is that the InternalUseOnlyPointcutParser is a million miles away from the parser that had the extension registered. My temporary fix is to associate registered handlers with the Scope within which the pointcuts are being processed. If we do this up front and pass the scope all the way through, the secondary pointcut parsers that are created can use the same set of extensions and it works fine (or at least the test doesnt fail for this reason any more...). I just need to justify to myself that this is a suitable use of scope. Ramnivas - if you want to try it out (and see if the tests are now failing for valid reasons...) I've uploaded a working weaver to: http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/aspectjweaver-spring.jar (Might take a while to appear due to replication) I'll think about the solution I've implemented whilst on my run...
Tested with aspectjweaver-spring.jar. Indeed, that fixes the problem (now tests fail for valid reasons).
Testcases and fix committed. I found a much cleaner way to do it on revisiting the bug - extensions to pointcut parsing are associated with the world in which resolution happens for the pointcut parser instance. So all pointcut parsers sharing a world share the set of registered extensions.
