Make localeResolver overridable via @ConditionalOnMissingBean#15751
Closed
codeconsole wants to merge 1 commit into
Closed
Make localeResolver overridable via @ConditionalOnMissingBean#15751codeconsole wants to merge 1 commit into
codeconsole wants to merge 1 commit into
Conversation
I18nAutoConfiguration registered the `localeResolver` bean
unconditionally. As a result, any application- or plugin-supplied
LocaleResolver produced a bean-definition override of the framework
default - a warning by default, and a hard startup failure when
spring.main.allow-bean-definition-overriding=false.
Spring Boot's own WebMvcAutoConfiguration.localeResolver() is annotated
@ConditionalOnMissingBean for exactly this reason. Apply the same so the
Grails default backs off cleanly when a localeResolver bean is already
present.
The condition is keyed on the bean name rather than the type:
DispatcherServlet resolves the locale resolver by the fixed
DispatcherServlet.LOCALE_RESOLVER_BEAN_NAME ("localeResolver"), so a
LocaleResolver bean registered under a different name would not be the
one actually used.
🚨 TestLens detected 5 failed tests 🚨Here is what you can do:
Test SummaryCI - Groovy Joint Validation Build / build_grails > :grails-test-examples-app1:integrationTest
CI - Groovy Joint Validation Build / build_grails > :grails-test-examples-scaffolding:integrationTest
CI / Functional Tests (Java 21, indy=false) > :grails-test-examples-app1:integrationTest
CI / Functional Tests (Java 21, indy=true) > :grails-test-examples-app1:integrationTest
CI / Functional Tests (Java 25, indy=false) > :grails-test-examples-app1:integrationTest
🏷️ Commit: dbee13e Test FailuresBookFunctionalSpec > Test that switching language results in correct encodings (:grails-test-examples-app1:integrationTest in CI / Functional Tests (Java 21, indy=false))
BookFunctionalSpec > Test that switching language results in correct encodings (:grails-test-examples-app1:integrationTest in CI / Functional Tests (Java 21, indy=true))
BookFunctionalSpec > Test that switching language results in correct encodings (:grails-test-examples-app1:integrationTest in CI / Functional Tests (Java 25, indy=false))
BookFunctionalSpec > Test that switching language results in correct encodings (:grails-test-examples-app1:integrationTest in CI - Groovy Joint Validation Build / build_grails)
UserControllerSpec > User list (:grails-test-examples-scaffolding:integrationTest in CI - Groovy Joint Validation Build / build_grails)Muted TestsSelect tests to mute in this pull request:
Reuse successful test results:
Click the checkbox to trigger a rerun:
Learn more about TestLens at testlens.app. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
I18nAutoConfiguration.localeResolver()registers thelocaleResolverbean unconditionally. As a result, an application-suppliedLocaleResolveroverrides the framework default — a bean-definition override warning on startup by default, and a hard startup failure whenspring.main.allow-bean-definition-overriding=false.This adds
@ConditionalOnMissingBean(name = "localeResolver")so the Grails default backs off cleanly when the application already defines one. This mirrors Spring Boot's ownWebMvcAutoConfiguration.localeResolver(), which is@ConditionalOnMissingBeanfor exactly this reason — registering it unconditionally is the divergence.Scope — what this covers
@ConditionalOnMissingBeanis evaluated during auto-configuration, so it lets the Grails default back off in favor of alocaleResolverbean that is already present at that point:@Bean localeResolver(user@Configurationis processed before auto-configuration),@Imported configuration, or@AutoConfigureBeforegrails-i18n.It does not affect beans contributed after auto-configuration — e.g. a Grails plugin's
doWithSpring, which is registered later and still overrides via the normal override mechanism. Silencing that case additionally requires the contributor to register its resolver during auto-config (e.g. an@AutoConfigureBefore(I18nAutoConfiguration)class) so this condition can see it and back off. This PR is the upstream half that makes such a clean backoff possible.Behavior for a plain app (no competing
localeResolver) is unchanged: the condition passes and the Grails default registers as before.Why keyed on the name, not the type
DispatcherServletresolves the locale resolver by the fixed bean nameDispatcherServlet.LOCALE_RESOLVER_BEAN_NAME("localeResolver"). ALocaleResolverbean registered under a different name is never the one actually used, so keying the condition on the bean name matches the real lookup semantics — a by-type condition could back off for an unrelated resolver bean thatDispatcherServletignores.Note
The sibling beans in the same class (
localeChangeInterceptor,messageSource) are also registered unconditionally; this PR is intentionally scoped tolocaleResolveronly. Happy to extend if maintainers prefer.