Menu
▾
▴
springframework-developer
|
From: Juergen H. <ju...@in...> - 2005-04-08 10:08:38
|
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 |
|
From: Matt S. <sga...@us...> - 2005-04-08 13:33:39
|
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 |
|
From: Matt R. <li...@ra...> - 2005-04-08 15:40:59
|
On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote: > 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. If I understand these classes correctly, it should be fairly simple to add this to your own filter: LocaleContextHolder.setLocale(request.getLocale()); I wonder if adding this to the CharacterEncodingFilter would make any sense? Matt > > 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 |
|
From: Colin S. <col...@ex...> - 2005-04-08 16:19:14
|
Matt Raible wrote: > > On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote: > >> 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. > > > If I understand these classes correctly, it should be fairly simple to > add this to your own filter: > > LocaleContextHolder.setLocale(request.getLocale()); > > I wonder if adding this to the CharacterEncodingFilter would make any > sense? > For people using Spring MVC you definitely still want to have DispatcherServlet do it (whether directly as now, or by reusing common code), without people having to put in the filter. I'm not so sure about combining the functionality into the CharacterEncodingFilter. Somewhat different concerns here, and you might want to handle the locale without touching the character encoding... -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - "From the Source" http://www.springframework.com |
|
From: Matt R. <li...@ra...> - 2005-04-08 16:48:51
|
On Apr 8, 2005, at 10:19 AM, Colin Sampaleanu wrote: > Matt Raible wrote: > >> >> On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote: >> >>> 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. >> >> >> If I understand these classes correctly, it should be fairly simple >> to add this to your own filter: >> >> LocaleContextHolder.setLocale(request.getLocale()); >> >> I wonder if adding this to the CharacterEncodingFilter would make any >> sense? >> > For people using Spring MVC you definitely still want to have > DispatcherServlet do it (whether directly as now, or by reusing common > code), without people having to put in the filter. I'm not so sure > about combining the functionality into the CharacterEncodingFilter. > Somewhat different concerns here, and you might want to handle the > locale without touching the character encoding... Right, but for those using something like Tapestry or JSF - they'll need to write their own filter. Since it's such little code, I don't see the need to provide a Spring Filter as part of the core, but it might be a good idea to note the Filter (and code) in the LocaleContextHolder's javadoc. I agree that it probably shouldn't go in the CharacterEncodingFilter - I'm just always looking for filter consolidation. I can probably add the above code to an existing filter. Matt > > -- > Colin Sampaleanu > Interface21 Principal Consultant > Spring Training, Consulting and Support - "From the Source" > http://www.springframework.com > > > > ------------------------------------------------------- > 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 |
|
From: Matt S. <sga...@us...> - 2005-04-08 16:49:34
|
I agree that you want the DispatcherServlet to work as it used to and not require a new filter to be added to Spring MVC apps. I'm just suggesting that making some of the DispatcherServlet's functionality accessible to non-Spring MVC users could be beneficial. It could also make the implementation of the <spring> tags more straightforward. Matt Colin Sampaleanu wrote: > Matt Raible wrote: > >> >> On Apr 8, 2005, at 7:32 AM, Matt Sgarlata wrote: >> >>> 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. >> >> >> >> If I understand these classes correctly, it should be fairly simple to >> add this to your own filter: >> >> LocaleContextHolder.setLocale(request.getLocale()); >> >> I wonder if adding this to the CharacterEncodingFilter would make any >> sense? >> > For people using Spring MVC you definitely still want to have > DispatcherServlet do it (whether directly as now, or by reusing common > code), without people having to put in the filter. I'm not so sure about > combining the functionality into the CharacterEncodingFilter. Somewhat > different concerns here, and you might want to handle the locale without > touching the character encoding... > |
|
From: Juergen H. <ju...@in...> - 2005-04-08 16:42:56
|
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 |
