This PR provides two commits that improve CookieLocaleResolver
, as a follow-up on #27609:
- Simplify creation of
CookieLocaleResolver
with custom cookie name
At present, creating CookieLocaleResolver
with custom cookie name requires creating an instance using the default constructor and then using setter to configure the desired cookie name.
This commit introduces CookieLocaleResolver
constructor that accepts cookie name thus allowing for a simpler creation of an instance with the desired cookie name.
- Refactor
CookieLocaleResolver
At present, CookieLocaleResolver
extends CookieGenerator
instead of AbstractLocale(Context)Resolver
like other LocaleResolver
implementations. This means it duplicates some common aspects of LocaleResolver
hierarchy while also exposing some CookieGenerator
operations, such as #addCookie
and #removeCookie
.
Additionally, CookieGenerator
's support for writing cookies is based on Servlet support which at current baseline doesn't support SameSite directive.
This commit refactors CookieLocaleResolver
to make it extend AbstractLocaleContextResolver
and also replaces CookieGenerator
's cookie writing support with newer and more capable ResponseCookie
.
Comment From: rstoyanchev
I've also added some improvements in ResponseCookie
to make it more friendly for use in CookieLocalResolver
so that it doesn't have to replicate all of its fields.
Comment From: sabomichal
It seems that introducing cookie
as an internal property, you made the whole class non thread safe. You are mutating the internal state even when cookie value is set. Is this an intended behavior?
Comment From: sbrannen
@sabomichal, this issue was closed almost 2 years ago.
If you believe you have encountered a bug or something worth discussing, please create a new issue.