Need to be able to call setLocale from within resolveLocale in custom LocaleResolver [SPR-10618]

[spring-projects-issues]

Nick Williams opened SPR-10618 and commented

I want to be able to do this in a custom LocaleResolver:

• Use the logged-in Principal's locale, if he has one.
• If not, use the locale specified in a cookie, if it exists.
• If not, use the Accept-Language header.

That in itself isn't that difficult. However, I also want to detect if the Principal's locale has been changed (for example, on a user profile settings page) and, if it has, update the cookie. The only way to do this is by calling the setLocale method from the resolveLocale method. For example:

public class UserCookieHeaderLocaleResolver extends CookieLocaleResolver {
    @Override
    public Locale resolveLocale(HttpServletRequest request) {
        Locale locale = super.resolveLocale(request);

        Principal user = request.getUserPrincipal();
        if(user != null && user instanceof FooPrincipal) {
            Locale userLocale = ((FooPrincipal)user).getLocale();
            if(userLocale != null && !userLocale.equals(locale)) {
                locale = userLocale;
                this.setLocale(request, ???, userLocale);
            }
        }

        return locale;
    }
}

However, there is the obvious problem that the resolveLocale method has no access to the HttpServletResponse. It would be great if this paramater could be added to the resolveLocale signature. The change itself is trivial, but the impact is major, hence why I marked this a major improvement.

I know interfaces can change between major versions, but I'm not sure how willing the community is going to be to change this particular method.

Thoughts?

---

Affects: 4.0 M1

[spring-projects-issues]

Nick Williams commented

After doing extensive work to implement #6227, I've determined that the request made in this issue here is simply not feasible. There are too many methods that call resolveLocale, and those methods only have access to the request, so their signatures would have to change, but there are other methods that call that that only have access to the request, and so on. It would be a refactor of monumental order and break tons of existing code, not just in the framework but also in applications using it.

So now that we've established that, my next question is, what about a ResponseContextHolder to mirror RequestContextHolder? That would enable the same thing and not require changing existing APIs.

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.