Re: [Springframework-developer] Re: LocaleContext

[Juergen H. <ju...@in...>]

I'm proposing to remove the generic Context interface completely. It seems
to me that Acegi should concentrate on its specific SecureContext, held in a
SecureContextHolder. It will only ever hold a SecureContext; after all, it's
a security framework, isn't it :-)

A single holder for a generic Context doesn't help much unless you have a
central controlling place where you manage the Context (which somewhat goes
against Spring's philosophy). For loosely coupled code, it's better to have
a specific Context for each subsystem, managed independently (in independent
ThreadLocals, i.e. independent holder classes).

Regarding LocaleContext management outside DispatcherServlet: Note that
DispatcherServlet does something very specific there - it delegates to its
LocaleResolver to resolve the Locale. Outside of Spring Web MVC, there is no
such LocaleResolver. We could probably extend our Struts support to expose
the Struts-determined Locale as a LocaleContext, though.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matt Sgarlata
Sent: Friday, April 08, 2005 3:32 PM
To: spr...@li...
Subject: [Springframework-developer] Re: LocaleContext


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



-------------------------------------------------------
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
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer