[Springframework-developer] Re: LocaleContext

[Matt S. <sga...@us...>]

Are you proposing to remove the Context interface or to move it to 
Spring core?  I think moving it to Spring core could be good.  However, 
I would make it a blank interface and add a ValidatableContext 
subinterface that defines the validate() method.

Could we have the LocaleContext also be automatically setup in the 
DelegatingRequestProcessor for Struts users?  Alternatively, perhaps 
some of the work that's currently done by the DispatcherServlet could be 
moved to a servlet filter that could work with any web application?  For 
backwards compatability, the DispatcherServlet could detect whether the 
new filter has already been invoked, and if not invoke it manually.

Matt

PS - Spring MVC is soooo much better than Struts, but I simply don't 
have the time to switch to it.  We already have too much momentum with 
Struts.

Juergen Hoeller wrote:
> I've introduced a LocaleContext abstraction and LocaleContextHolder class in
> "org.springframework.context.i18n". DispatcherServlet automatically
> populates LocaleContextHolder's ThreadLocal (delegating to LocaleResolver),
> and MessageSourceAccessor automatically uses the current Locale from there
> (falling back to the system default Locale).
> 
> The LocaleContext is essentially analogous to Acegi's SecurityContext. I
> guess it's better to keep such contexts separate, though, else it'll be
> unclear who choses the Context implementation to use etc. To express this,
> it might make sense to remove the generic Context interface from Acegi, only
> keeping a SecurityContext, held in a SecurityContextHolder.
> 
> Thoughts?
> 
> Juergen
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click