At present, the customization of the default locale and timezone resolution in CookieLocaleResolver and SessionLocaleResolver requires subclassing them and overriding determineDefaultLocale and/or determineDefaultTimeZone methods.

This PR simplifies resolution of the default locale and timezone resolution by introducing dedicated functions for these purposes, thus allowing the customization without needing to resort to subclassing the locale resolvers.

Additionally, there are also 2 small commits that improve some aspects of the LocaleResolver hierarchy: - Update AcceptHeaderLocaleResolver to extend AbstractLocaleResolver: This commit updates AcceptHeaderLocaleResolver to extend AbstractLocaleResolver, which allows the removal of defaultLocale managing code in AcceptHeaderLocaleResolver.

  • Update LocaleContextResolver to implement LocaleResolver: This commit updates LocaleContextResolver to implement LocaleResolver using default methods, which simplifies AbstractLocaleContextResolver and aligns it more closely with AbstractLocaleResolver.

Comment From: vpavic

Any feedback on this?

Comment From: sbrannen

Any feedback on this?

Hi @vpavic,

We just have not gotten to it yet.

We'll review it and hopefully get it into 6.0 M5.

Comment From: vpavic

Thanks @sbrannen.

In my notes I had a few other improvement proposals that weren't as straightforward as those included in this PR:

  • refactor CookieLocaleResolver to extend AbstractLocaleContextResolver, and delegate to CookieGenerator instead of extending it - this would eliminate some duplication but would also introduce some breaking changes (that are IMO welcome as CookieLocaleResolver doesn't really need many of the methods it inherits from the CookieGenerator and would also really need a constructor that takes cookie name).
  • introduce AcceptHeaderLocaleContextResolver that would replace AcceptHeaderLocaleResolver and align with reactive side (which offers org.springframework.web.server.i18n.AcceptHeaderLocaleContextResolver) - that would also open the path for deprecating org.springframework.web.servlet.LocaleResolver.

Anyway, let me know what you think of those and I can either add commits to this PR or open separate issues (or PRs) to consider those separately. IMO the whole LocaleResolver hierarchy could use some modernization and chances to do so (that is, new major releases) don't come too often.

Comment From: sbrannen

Anyway, let me know what you think of those and I can either add commits to this PR or open separate issues (or PRs) to consider those separately.

I'll assess that after merging the three commits in this PR.

IMO the whole LocaleResolver hierarchy could use some modernization and chances to do so (that is, new major releases) don't come too often.

Indeed, 6.0 is a good opportunity for "modernization".