AOP and Groovy not working together (again)

[krancour]

Today I was attempting to use <aop:aspectj-autoproxy.../> in conjunction with some Groovy beans, and much to my dismay, I found that this gives me all kinds of trouble.

It seems that the Groovy bean (as defined below) is not visible to AspectJ weaver's classloader.

<lang:groovy id="echoService.groovy" script-source="classpath:/com/kent/echo/GroovyEchoService.groovy">
  <lang:property name="prefix" value="Groovy"/>
</lang:groovy>

I get an xlint exception from ReflectionWorld indicating that com.kent.echo.GroovyEchoService is not found.

This problem is described in much greater detail in this old forum post (link below) and the thread seems to be conluded with a fix that was included in Spring 2.0.3, however, I am using Spring 3.0.4 and am still seeing this issue.

http://forum.springsource.org/showthread.php?t=35350

Here's the corresponding entry in JIRA (which indicates the problem was fixed):

https://jira.springframework.org/browse/SPR-3223

Any help would be greatly appreciated!

[Enrico Pizzi]

This sounds quite normal to me...groovy beans are dynamic and as such are compiled on the fly when needed, using the Groovy class loader....not the AspectJ class loader which of course can't find the class it needs. If you want to make this work, precompile your .groovy files into .class during build using a groovyc ant task.

[krancour]

I beg to differ. Many beans in Spring are compiled "dynamically, on the fly" as you say. Case in point, nearly any bean that is proxied in any way- be it for WS-* support, lightweight remoting, invoking an SLSB, or because there is AOP being applied to the bean- that proxy is created dynamically using either CGLIB or JDK dynamic proxying. In either case, the result is bean and can be treated just like any other bean. This means that it itself can be proxied.

In the case of the Groovy bean in particular, you would find that lang:groovy is just some syntactic sugar around a GroovyScriptFactory. The bean that is produced implements all Java interfaces that are specified in the script, and should be eligible for proxying if the pointcut expression in question specifies that is the case.

You're quite incorrect in saying that this isn't supposed to work, and in fact, if you read the links I provided, you will find that not only has this issue been reported before, but Juergen also acknowledged there was an issue and corrected it. This seems to be a recurrence of that same issue.

Re: the classloader issue. You have hit the nail on the head as to why this doesn't work. In my case, the GroovyClassloader is a child of the WAR classloader. As such, AspectJ weaver- also loaded at the WAR level- has no visibility into the bean in question (which at this point in the lifecycle is compiled). Again, it seems this is the very issue that had already been addressed once before and is now recurring.