This PR wraps up efforts to improve org.springframework.web.servlet.LocaleResolver hierarchy started in:

  • https://github.com/spring-projects/spring-framework/pull/27609
  • https://github.com/spring-projects/spring-framework/pull/28779

The core change proposed here (first commit) is to refactor AcceptHeaderLocaleResolver to implement LocaleContextResolver, which makes the all locale resolvers provided by Spring MVC LocaleContextResolver based. It also aligns Spring MVC with Spring WebFlux, where all resolvers work with LocaleContext rather than plain Locale.

The two subsequent commits are optional, but could be helpful as they prepare ground to simplifying LocaleResolver hierarchy in the future:

  • second commit deprecates AbstractLocaleResolver in favor of AbstractLocaleContextResolver, as nothing is using AbstractLocaleResolver after the first commit
  • third commit is a bit more substantial as it deprecates org.springframework.web.servlet.LocaleResolver and reworks all the references to operate against LocaleContextResolver - while technically a breaking change, this only impacts those with custom LocaleResolver that don't implement LocaleContextResolver

Comment From: jhoeller

While I see the point of the PR, I am not inclined to proceed with phasing out LocaleResolver which has been around for 20 years. AcceptHeaderLocaleResolver implementing LocaleContextResolver does not provide any user-level benefits on its own (since the accept-header strategy is only capable of providing a plain locale to begin with). From my perspective, this would really have go along with a deprecation of LocaleResolver as per your third commit, and that's what I try not to inflict on the two-decade-long usage this has in configuration points, customizations/decorations, and also in testing scenarios.

Point taken that WebFlux has full-scale LocaleContext resolution. However, since that is not the only difference that shows MVC's age over WebFlux, that level of SPI style alignment between MVC and WebFlux is not a goal per se... as long as the overall capabilities are equivalent.