Spring’s LocaleContextHolder temporarily binds a Locale (and optionally TimeZone) to the current thread. It’s typically set at the beginning of a HTTP request and cleared at the end.
Now I want the Vaadin UI or session to be the source of the locale, but still allow LocaleContextHolder to be used for maximum compatibilty, if at all possible.
I can somewhat replicate this for Vaadin with a RequestHandler (I can set the locale, but clearing probably requires a separate servlet filter). But this still wouldn’t work when accessing the UI from a background thread. There doesn’t seem to be any hook (and why would there be), but maybe I’m missing something?
I’m not willing to do anything invasive (like extending SpringServlet etc); that’s definitely not worth it :)
But I’m beginning to think that my mistake is trying to salvage LocaleContextHolder in the first place.
Akin to SecurityContextHolder, I want the user’s locale (and time zone) to be available anywhere within UI-related code without having to pass it around everywhere. So I was reusing LocaleContextHolder and setting the UI’s locale in it myself (via said RequestHandler). This seemed to work fine for the most part, but fell flat for background threads accessing the UI. There doesn’t seem to be a way to prepare the SecurityContextHolder for those.
So I’m wondering if there’s a way to salvage this, or if LocaleContextHolder is just a lost cause for Vaadin and I should just use UI#getLocale() since UI#getCurrent() is always available in a UI thread, regardless of how you got there.
I personally would go with the assumption that the locale provided by the user stays stable - allowing me to use a UI Init Listener to fetch it from the client and storing the user provided locale on the UI.
I’ll take that as a “Just forget about LocaleContextHolder!” :)
My I18NProvider knows which locales (i.e. translations) are available, so Vaadin can already pick the best one based on the request header. There’s also a facility in place to extract a locale from a successful authentication and store it in the Vaddin session. So that part I have covered and my question was really only about LocaleContextHolder.
This is part of a library, so I’m especially trying to reuse and integrate, not reinvent the wheel. But it seems this is simply not feasible for LocaleContextHolder. Which should be fine; so far I don’t think anything important relies on it - at least in the realm of Vaadin. But we’ll see.
True. Though in my case, Vaadin out of the box already does a much better job at picking the best matching locale from the provided ones.
Bye bye, LocaleContextHolder :)