Re: [Springframework-developer] Binding Locale to threadlocal

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

This was brought up by one person on the forum in early Oct or so, and 
since that message, two other people have asked. I think this makes a 
decent amount of sense as an optional thing. While I agree that at some 
level (a utility function of some sort) it makes sense to always pass in 
the locale, above that level it becomes debatable depending on the 
actual circumstances. If you're always passing in the locale to a bunch 
of function it's possibly a code smell... I would personally leave it up 
to people implementing that app, but put appropriate warnings in the 
documentation.

In terms of a user context, Acegi Security System already has something 
like this for security information, and theorectically for other stuff 
too. It may make sense to make a class for this purpose for Spring.


jürgen höller [werk3AT] wrote:

>Colin,
> 
>Do you have a concrete use case for this? I've personally not needed implicit locale access in the middle tier, and I'm not sure if business objects should rely on a thread-bound locale. I tend to pass the locale explicitly as argument in my business methods, which can then in turn be passed to a MessageSource or MessageSourceAccessor.
> 
>One advantage of an explicit locale argument is that the choice of locale for a specific operation is completely up to the view layer. For example, a report can be generated in English (through passing the English locale to a business operation as explicit argument), despite the user interface language (as determined by LocaleResolver in Spring web MVC) being German.
> 
>I guess we should first discuss whether we actually want to build thread-bound locale resolution into the framework, which people would see as general recommendation for such an approach. I tend to recommend explicit locale arguments instead... There is an argument that a specific locale for a given servlet request only applies to the web user interface itself, not necessarily to all business operations triggered by it.
> 
>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.
> 
>Open for discussion :-)
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: So 05.12.2004 21:56
>An: spr...@li...
>Betreff: [Springframework-developer] Binding Locale to threadlocal
>
>
>
>I'm thinking of the best strategy for making the locale available to the
>MessageSourceAccessor, as per SPR-485:
>  http://opensource.atlassian.com/projects/spring/browse/SPR-485
>This would probably be a TheadLocal that the locale is bound to. The
>question is what the best strategy to do this is. I suppose
>DispatcherServlet could just bind the locale to a threadlocal, using the
>configured LocaleResolver, before dispatching. The problem here is that
>it won't pick up a changed locale as a result of a setLocale call on the
>localeresolver by the web code. Alternately, a ControllerInterceptor
>would have the same limitation, and would also have to be configured in
>front of every controller. What I am thinking would perhaps work though
>is something like a new Interface called LocaleAccessor. The
>implementation would be a JavaBean, and would be bound to the thread by
>the dispatcher. What it would hold would be both the Servlet Request,
>and also the LocaleResolver. When asked to get the Locale, it would be
>able to use the normal localeresolver, since it would also have the request.
>
>The whole point of this is so that non-view layer code can have access
>to locale resolution, in a similar fashion to view layer code.
>
>Can anybody think of a better mechanism?
>
>Colin
>  
>