Re: [Springframework-developer] Binding Locale to threadlocal

[Ben A. <ben...@ac...>]

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.

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.

Best regards
Ben