LocaleResolver (MVC) and LocaleContextResolver (WebFlux) beans will back off if a user provides a bean of the same type and a custom name but Framework will then use its own default

[wilkinsona]

While looking at #24207, I noticed that our overrides of the localeResolver() (MVC) and localeContextResolver() (WebFlux) methods will back off if any LocaleResolver or LocaleContextResolver bean is present (they're annotated with a plain @ConditionalOnMissingBean) but Framework consumes these beans using a specific name. This means that a user may provide a custom bean with a non-standard name and our auto-configuration will back off, but Framework will then use its default rather than the user's bean. If you're trying to figure out what's happened, the condition evaluation report won't help much as it'll show that the auto-configured resolver backed off in favour of the user-provided resolver but won't explain why the user-provided resolver wasn't used.

I am wondering if our auto-configured beans should only back off when a bean of the name that Framework looks for is defined:

@ConditionalOnMissingBean(name = WebHttpHandlerBuilder.LOCALE_CONTEXT_RESOLVER_BEAN_NAME)

@ConditionalOnMissingBean(name = DispatcherServlet.LOCALE_RESOLVER_BEAN_NAME)

This would make the condition evaluation report more useful as it will show that the auto-configured bean was configured as no bean with a specific name was found in the context.

[philwebb]

I think we probably should. I'd even say this is a bug and should perhaps be fixed in 2.2.x

[wilkinsona]

The LocaleContextResolver problem is specific to 2.4.0. I'll fix the MVC side of things in 2.2.x and 2.3.x and both in 2.4.x.

[wilkinsona]

In 2.2 and 2.3 the auto-configured LocaleResolver is @ConditionalOnProperty(prefix = "spring.mvc", name = "locale"). For the problem described above to occur, you'd have to set the spring.mvc.locale property and provide a custom LocaleResolver bean that isn't named localeResolver(). I think that's sufficiently unlikely to happen that the risk of the fix isn't worth the marginal improvement.

In 2.4.0 things are different as both the LocaleResolver and LocaleContextResolver beans are not @ConditionalOnProperty.