Re: [Springframework-developer] Binding Locale to threadlocal

[Tim K. <tim...@vi...>]

Hi all,

I am following this discussion with great interest, because my coworker=20=

and I have been tossing back and forth some ideas of having a=20
threadbound context for our project as well.  I had been planning on=20
piggybacking upon the acegi context instance to hold user locale=20
information, along with other types of information we may need to make=20=

available.

So, to regards with Ben's suggestion for making acegi's context more=20
general (part of spring core), would be a move that would be greatly=20
beneficial for us as well.    A context, along with some utility=20
classes to expose the context and locale information in the application=20=

would be nice.

On Dec 5, 2004, at 5:20 PM, Ben Alex wrote:

> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> On the other hand, if many of your business operations would end up=20=

>> with explicit locale arguments, an implicit locale context does make=20=

>> sense, possibly combined with a general user context that also=20
>> contains authorization info etc. A custom HandlerInterceptor should=20=

>> be able to expose the current Locale (or a LocaleAccessor delegating=20=

>> to the LocaleResolver) via such a ThreadLocal; this does not=20
>> necessarily have to be built into DispatcherServlet itself.
>>
>>
>>
> One use case we've encountered where having a Locale available in the=20=

> services layer would be helpful is with exception message resolution.=20=

> Generally you want to throw an Exception which is already populated=20
> with a message the user can actually read. Whilst you could catch=20
> exceptions in the view layer and populate the messages, it seems=20
> double-handling of exceptions which could be avoided.
>
> Acegi Security provides a general-purpose ContextHolder and it would=20=

> be easy to edit one of the existing filters to pop the Locale into the=20=

> ContextHolder on every request. An issue that comes to mind is whether=20=

> support should be provided to explicitly change the browser-sourced=20
> Locale via a web controller or filter, or solely rely on the browser=20=

> headers. Obviously the latter is simplest, and avoids HttpSession=20
> dependency, at the possible expense of the user experience or=20
> requirements.
>
> Another issue to consider is the integration with rich clients. It's=20=

> often fairly easy to pass a general-purpose Context (or its core=20
> contents) from a rich client tier to a services tier. For example,=20
> Acegi Security provides automatic propagation of the ContextHolder=20
> contents for RMI invocations (so the Locale could traverse the tiers)=20=

> and automatic propagation of the username and password in the=20
> ContextHolder for HttpInvoker invocations (which could easily be=20
> extended to obtain the Locale and set the necessary HTTP headers=20
> accordingly).
>
> IMHO developing a general-purpose Context for authentication and=20
> locale resolution therefore could be useful addition. If this were to=20=

> happen, I would encourage Context management become part of Spring=20
> Core so that its MVC classes and remoting classes in particular could=20=

> offer fuller integration. The existing Acegi Security context model=20
> might provide some starting point (see class diagram at=20
> http://acegisecurity.sourceforge.net/docbook/Context.gif). I would=20
> happily change Acegi Security to support a Spring Core based user=20
> context management approach.
>
> Best regards
> Ben
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users.
> Discover which products truly live up to the hype. Start reading now.=20=

> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>