Re: [Springframework-developer] Binding Locale to threadlocal

[Colin S. <col...@ex...>]

Ben Alex wrote:

> jürgen höller [werk3AT] wrote:
>
>> On the other hand, if many of your business operations would end up 
>> with explicit locale arguments, an implicit locale context does make 
>> sense, possibly combined with a general user context that also 
>> contains authorization info etc. A custom HandlerInterceptor should 
>> be able to expose the current Locale (or a LocaleAccessor delegating 
>> to the LocaleResolver) via such a ThreadLocal; this does not 
>> necessarily have to be built into DispatcherServlet itself.
>
> One use case we've encountered where having a Locale available in the 
> services layer would be helpful is with exception message resolution. 
> Generally you want to throw an Exception which is already populated 
> with a message the user can actually read. Whilst you could catch 
> exceptions in the view layer and populate the messages, it seems 
> double-handling of exceptions which could be avoided.
>
> Acegi Security provides a general-purpose ContextHolder and it would 
> be easy to edit one of the existing filters to pop the Locale into the 
> ContextHolder on every request. An issue that comes to mind is whether 
> support should be provided to explicitly change the browser-sourced 
> Locale via a web controller or filter, or solely rely on the browser 
> headers. Obviously the latter is simplest, and avoids HttpSession 
> dependency, at the possible expense of the user experience or 
> requirements.

Spring already has the LocaleResolver mechanism, which is pluggable, 
with different variations existing, 3 of which fall back to using the 
locale specified by the request if the main one fails (i.e. there is no 
cookie, when using the CookieLocaleResolver. I think it makes sense that 
any scheme which passes a locale down to the service layer ensures that 
this is, or at least it's possible for it to be, the same locale after 
as you would get by using the configured LocaleResolver from the web 
layer. But this actually potentially get's tweaked by the web controller 
itself (by calling setLocal() for example). This is why I suggested that 
what gets bound (in one variation at least) is actually an object 
holding and delegating to the real LocaleResolver and the request. This 
could then be bound conveniently (for Spring MVC) via a 
HandlerInterceptor. For the non-Spring MVC case you would probably do it 
via a generic servlet filter, which binds an object supporting the same 
interface (LocaleAccessor?). Even in that case there could be a real 
LocaleResolver and request backing it, or alternately something more 
static...

>
> Another issue to consider is the integration with rich clients. It's 
> often fairly easy to pass a general-purpose Context (or its core 
> contents) from a rich client tier to a services tier. For example, 
> Acegi Security provides automatic propagation of the ContextHolder 
> contents for RMI invocations (so the Locale could traverse the tiers) 
> and automatic propagation of the username and password in the 
> ContextHolder for HttpInvoker invocations (which could easily be 
> extended to obtain the Locale and set the necessary HTTP headers 
> accordingly).
>
> IMHO developing a general-purpose Context for authentication and 
> locale resolution therefore could be useful addition. If this were to 
> happen, I would encourage Context management become part of Spring 
> Core so that its MVC classes and remoting classes in particular could 
> offer fuller integration. The existing Acegi Security context model 
> might provide some starting point (see class diagram at 
> http://acegisecurity.sourceforge.net/docbook/Context.gif). I would 
> happily change Acegi Security to support a Spring Core based user 
> context management approach.

I think this makes some sense. This is why I mentioned the Acegi 
Security stuff...