MVC handler method detection should ignore scopedTarget.x in favor of corresponding proxy bean [SPR-11548]

[spring-projects-issues]

Dave Syer opened SPR-11548 and commented

According to #11780 I would expect that scoped targets are not autowire candidates and therefore would not cause problems with autowiring using @Autowired. But if I define a @Bean @Lazy @Scope(proxyMode=INTERFACES) all the @Autowired sites for beans of that type blow up (2 beans of the same type are found: x and scopedTarget.x).

---

Affects: 4.0.2

Issue Links:

• Consistent bean type checking for endpoint handlers [SPR-13725] #18298 Consistent bean type checking for endpoint handlers

0 votes, 6 watchers

[spring-projects-issues]

Juergen Hoeller commented

Dave, ScopedProxyUtils.createScopedProxy does apply setAutowireCandidate(false) to the target definition, and even with a very specific unit test, I'm unable to reproduce the behavior that you're seeing. It works fine for both @Autowired and getBean(Class), so I suspect there is something subtle in your scenario that affects the autowire candidate status...

Juergen

[spring-projects-issues]

Dave Syer commented

I'm working on it. I also wasn't able to reproduce with a vanilla test case. I have a feeling it's a Spring Security thing (cc: Rob Winch), but it could have been Boot.

[spring-projects-issues]

Dave Syer commented

Here's a similar issue (adding @Bean @Lazy @Scope(paroxyMode=TARGET_CLASS) to a @Controller bean):

Caused by: java.lang.IllegalStateException: Ambiguous mapping found. Cannot map 'authorizationEndpoint' bean method 
public org.springframework.web.servlet.ModelAndView org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoint.authorize(java.util.Map<java.lang.String, java.lang.Object>,java.util.Map<java.lang.String, java.lang.String>,org.springframework.web.bind.support.SessionStatus,java.security.Principal)
to {[/oauth/authorize],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}: There is already 'scopedTarget.authorizationEndpoint' bean method
public org.springframework.web.servlet.ModelAndView org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoint.authorize(java.util.Map<java.lang.String, java.lang.Object>,java.util.Map<java.lang.String, java.lang.String>,org.springframework.web.bind.support.SessionStatus,java.security.Principal) mapped.
	at org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.registerHandlerMethod(AbstractHandlerMethodMapping.java:177)
	at org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.detectHandlerMethods(AbstractHandlerMethodMapping.java:149)
	at org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.initHandlerMethods(AbstractHandlerMethodMapping.java:109)
	at org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.afterPropertiesSet(AbstractHandlerMethodMapping.java:89)
...

I'll send an issue PR for that, and then keep looking for the Security issue: spring-attic/spring-framework-issues#70

[spring-projects-issues]

Juergen Hoeller commented

Indeed, our MVC handler method detection should also ignore scoped targets. We're not explicitly checking any of those flags there, simply treating scoped targets as regular beans... And it probably hasn't been reported simply because people usually don't define scoped proxies for controllers: The MVC dispatching infrastructure can handle lazy beans and scoped beans without scoped proxies as well.

So for that part, I'll add some kind of special check to the handler method detection algorithm. Probably not against the autowire-candidate attribute though, otherwise we'd overload the meaning of that flag... After all, people can manually set this to false too, in order to prevent by-type injection; that might make sense for controllers in some scenarios, while still supposed to be detected for MVC dispatching.

Juergen

[spring-projects-issues]

Phil Webb commented

spring-attic/spring-framework-issues#70