Groovy application with JSR-303 bean validation. Configured MethodValidationPostProcessor and LocalValidatorFactoryBean in groovy beans along with other beans. Application fails to start due to DI failure for beans using JSR-303 validation.
Relevant classes below. Actually using 4.0.4.BUILD-SNAPSHOT but JIRA won't let me choose that.
Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private name.abhijitsarkar.moviedatabase.service.rip.MovieRipService name.abhijitsarkar.moviedatabase.service.facade.MovieFacade.movieRipService; nested exception is java.lang.IllegalArgumentException: Can not set name.abhijitsarkar.moviedatabase.service.rip.MovieRipService field name.abhijitsarkar.moviedatabase.service.facade.MovieFacade.movieRipService to com.sun.proxy.$Proxy50
... 31 more
This looks like a proxy type mismatch, probably caused by your MethodValidationPostProcessor creating an interface proxy (for whatever interface it seems to detect here - could be an implicit Groovy interface)...
Does it help to call setProxyTargetClass(true) on your MethodValidationPostProcessor bean?
After some quick review here, it does seem like the presence of the GroovyObject interface on a Groovy bean class makes AbstractAdvisingBeanPostProcessor choose interface proxies - in that case, a proxy that just implements the GroovyObject interface :-(
In any case, setProxyTargetClass(true) should solve the immediate problem here. If it does, I'll turn this issue into a general AbstractAutoProxyCreator / AbstractAdvisingBeanPostProcessor enhancement to be smarter about GroovyObject there, not considering it as a user-specified interface and therefore choosing target-class proxies automatically if GroovyObject is the only interface being implemented.
This seems to be a general issue with the eligibility check in AbstractAdvisingBeanPostProcessor as it checks bean target class for eligibility which might be a proxy target type only. In case the proxy interface implements additional interfaces, methods on these interfaces are not considered during the matching against the registered pointcuts. Also discoverable in Spring 3.2.x releases.
setProxyTargetClass(true) or it's Groovy equivalent proxyTargetClass = true does solve the issue. Since I shouldn't have to do this, making AbstractAdvisingBeanPostProcessor smarter about the Groovy interfaces seems like the way to go.
AbstractAutoProxyCreator and AbstractAdvisingBeanPostProcessor consistently don't consider configuration callbacks and internal language interfaces as reasonable proxy interfaces now, through reusing the evaluateProxyInterfaces algorithm from a new common ProxyProcessorSupport base class. This includes exclusion of the GroovyObject interface; to be extended for any further well-known language interfaces that are just meant for internal use.