AspectJ pointcut advisors are not working with Groovy script beans [SPR-5749]

[spring-projects-issues]

Naresh Narayana opened SPR-5749* and commented

It seems that AOP is not working for Groovy beans.

---

Affects: 2.5.6

Reference URL: http://forum.springsource.org/showthread.php?t=71389

Attachments:

• testProject.zip (10.75 kB)

Issue Links:

• Annotated Groovy controllers don't work properly [SPR-6268] #10935 Annotated Groovy controllers don't work properly

Referenced from: commits bd0f68d

1 votes, 3 watchers

[spring-projects-issues]

Dave Syer commented

Neither the issue summary "Annotation based pointcut advisors are not working with refreshable Groovy beans" nor the comment turn out to be the whole story. The problem is not to do with being refreshable (although that has other issues, c.f. #10935). It is also not specifically about annotation-based pointcuts. And it is certainly not the case that AOP does not work for Groovy beans (there are test cases in spring-context that work fine).

The problem arises if the pointcut requires information about the class of the target because the GroovyClassLoader is not available to the AOP weaver. I'm not sure if it ever could be, but I'll ask Andy Clement to comment if he thinks there might be a chance at some point. So, pointcuts that won't work are @within and within definitely, and in addition any execution pointcuts that refer to the concrete class of the target, not its interfaces. I assume that binding expressions will also not work if they refer to the concrete type and not the interface.

[spring-projects-issues]

Andy Clement commented

Not quite sure how the wiring is done on the spring side, but the pointcut parser is initialized using the context classloader. In addition it may have its classloader reset later via PointcutParser.setClassLoader(ClassLoader). Does that enable you to tell AspectJ about the GCL? Or do you not even get to see the GCL?

[spring-projects-issues]

Dave Syer commented

This isn't going to be easy and may well be impossible to address. You do need to see the GCL I think - you don't need to know it is a GCL, but you need the ClassLoader from the class of the target scripted bean for AspectJ to match the point cut. The problem really is that, while it is reasonable to expect a Pointcut to be parseable from a "global" ClassLoader, the matching of the parsed expression with the target class has to have some knowledge of that class. So the matching and parsing are quite tightly coupled through the same ReflectionWorld.

The PointcutParser for Spring AOP is defined once globally for the whole BeanFactory, and initialized with a BeanFactory ClassLoader there (so not relying on the TCCL default in AspectJ). Then the script bean has its own (different) class loader. To make any progress here we would need to do something like catch ReflectionWorkExecption in a few more places in AspectJExpressionPointcut and, instead of assuming the worst, fallback to using an alternative PointcutParser based on the target class ClassLoader instead of the BeanFactory one. That's going to be quite messy and not a little hairy. Any other ideas, Andy?

You can see all the basic problems in AspectJExpressionPointcut.

[spring-projects-issues]

Andy Clement commented

You do need to see the GCL I think - you don't need to know it is a GCL, but you need the ClassLoader from the class of the target scripted bean for AspectJ to match the point cut.

Yep. The act of 'parsing' is also going to attempt some resolution, this means for non-wildcarded types (i.e. exact names) AspectJ is going to try and find them. For the pointcut here parsing may be OK because the @Log annotation isn't reliant on the GCL. But at match time we really need to be able to see that type to ask it if it has the annotation.

A 'fallback' solution seems possible, and relatively reliable (only needing to be attempted if the classloader is different to that already used to setup the pointcut parser, of course, and maybe also only if it is a GCL, if you can code that check in that code). Given that there is already some fallback in the getShadowMatch() function, maybe it isn't soooo bad.

[spring-projects-issues]

Dave Syer commented

It was a bit messy actually, but I think it's working now: if you declare it to be proxy-target-class then a refreshable groovy bean will match pointcuts in AOP interceptors. In the original sample I had to add @Inherited to the @Log annotation so that the pointcut matches the proxy as well (since it is a subclass).