You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've switched DelegatingWebMvcConfiguration to disable method proxying and there are a number of side effects that aren't currently covered.
requestMappingHandlerAdapter takes a mvcContentNegotiationManager, mvcConversionService and mvcValidator. These are "qualified" in the aim of calling the related method on the same class.
The problem with this approach is that if any of those types are already exposed with a @Primary bean, the context will not even attempt to look for a candidate (and therefore will not invoke the dedicated bean factory method if necessary).
A concrete illustration of this problem for mvcConverter can be found in spring-projects/spring-boot#18672. A fix is to add a @Qualifier to teach the context the qualified bean is actually required and the context should attempt to look it up.
This seems to be working as expected (although with more metadata than it should be ideally) but given that no tests broke, I can only assume this use case isn't covered by tests at the moment. The purpose of this issue is to revisit this support, add missing tests and eventually change our mind with regards to this decision.
The text was updated successfully, but these errors were encountered:
snicoll
changed the title
MVC configuration may not use expected infrastructure
Revisit @Configuration(proxyBeanMethods = false) with qualified injection points
Oct 30, 2019
This turned out to be a larger affair. Checking our use of @Configuration(proxyBeanMethods = false) when the injection point expect a qualified injection point. Production code seems rather limited at the moment:
This commit is a follow-up of a change in Spring Framework[1] to make
sure injection points that are expecting a specific bean by name use
a qualifier.
As a result of this change, MVC uses the dedicated MVC validator again
rather than the general one auto-configured by Spring Boot.
[1] spring-projects/spring-framework#23887Closesgh-18672
pullbot
pushed a commit
to scope-demo/spring-framework
that referenced
this issue
Oct 30, 2019
Previously, the infrastructure provided by WebMvcConfigurationSupport
and WebFluxConfigurationSupport can lead to unexpected results due to
the lack of qualifier for certain dependencies. Those configuration
classes refer to very specific beans, yet their injection points do not
define such qualifiers. As a result, if a candidate exists for the
requested type, the context will inject the existing bean and will
ignore a most specific one as such constraint it not defined. This can
be easily reproduced by having a primary Validator whereas a dedicated
"mvcValidator" is expected. Note that a parameter name is in no way a
constraint as the name is only used as a fallback when a single
candidate cannot be determined.
This commit provides explicit @qualifier metadata for such injection
points, renaming the parameter name in the process to clarify that it
isn't relevant for the proper bean to be resolved by the context.
Closesspring-projectsgh-23887
This relates to #23839
We've switched
DelegatingWebMvcConfiguration
to disable method proxying and there are a number of side effects that aren't currently covered.requestMappingHandlerAdapter
takes amvcContentNegotiationManager
,mvcConversionService
andmvcValidator
. These are "qualified" in the aim of calling the related method on the same class.The problem with this approach is that if any of those types are already exposed with a
@Primary
bean, the context will not even attempt to look for a candidate (and therefore will not invoke the dedicated bean factory method if necessary).A concrete illustration of this problem for
mvcConverter
can be found in spring-projects/spring-boot#18672. A fix is to add a@Qualifier
to teach the context the qualified bean is actually required and the context should attempt to look it up.This seems to be working as expected (although with more metadata than it should be ideally) but given that no tests broke, I can only assume this use case isn't covered by tests at the moment. The purpose of this issue is to revisit this support, add missing tests and eventually change our mind with regards to this decision.
The text was updated successfully, but these errors were encountered: