Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-12-05 21:51:08
|
Colin, =20 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. =20 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. =20 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. =20 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. =20 Open for discussion :-) =20 Juergen =20 ________________________________ 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 ------------------------------------------------------- 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://productguide.itmanagersjournal.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-12-05 22:10:39
|
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 > > |
|
From: Matt S. <sga...@us...> - 2004-12-06 01:26:36
|
> 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. If Spring does adopt some type of generic context notion, I strongly encourage you to take a look at the Context notion provided by the Morph framework. It is a very simple interface, yet it provides the methods needed to implement a Map, which is nice and generic for passing between tiers. The base class for implementers of Context, called BaseContext, implements Map. There are also other mechanisms in Morph to expose a Context as a Map. http://morph.sourceforge.net/apidocs/net/sf/morph/context/Context.html Matt |
|
From: Ben A. <ben...@ac...> - 2004-12-05 22:21:12
|
jürgen höller [werk3AT] wrote: > >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. > > > > One use case we've encountered where having a Locale available in the services layer would be helpful is with exception message resolution. Generally you want to throw an Exception which is already populated with a message the user can actually read. Whilst you could catch exceptions in the view layer and populate the messages, it seems double-handling of exceptions which could be avoided. Acegi Security provides a general-purpose ContextHolder and it would be easy to edit one of the existing filters to pop the Locale into the ContextHolder on every request. An issue that comes to mind is whether support should be provided to explicitly change the browser-sourced Locale via a web controller or filter, or solely rely on the browser headers. Obviously the latter is simplest, and avoids HttpSession dependency, at the possible expense of the user experience or requirements. Another issue to consider is the integration with rich clients. It's often fairly easy to pass a general-purpose Context (or its core contents) from a rich client tier to a services tier. For example, Acegi Security provides automatic propagation of the ContextHolder contents for RMI invocations (so the Locale could traverse the tiers) and automatic propagation of the username and password in the ContextHolder for HttpInvoker invocations (which could easily be extended to obtain the Locale and set the necessary HTTP headers accordingly). IMHO developing a general-purpose Context for authentication and locale resolution therefore could be useful addition. If this were to happen, I would encourage Context management become part of Spring Core so that its MVC classes and remoting classes in particular could offer fuller integration. The existing Acegi Security context model might provide some starting point (see class diagram at http://acegisecurity.sourceforge.net/docbook/Context.gif). I would happily change Acegi Security to support a Spring Core based user context management approach. Best regards Ben |
.){kind=link}
|
From: Colin S. <col...@ex...> - 2004-12-06 03:06:12
|
Ben Alex wrote: > jürgen höller [werk3AT] wrote: > >> 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. > > One use case we've encountered where having a Locale available in the > services layer would be helpful is with exception message resolution. > Generally you want to throw an Exception which is already populated > with a message the user can actually read. Whilst you could catch > exceptions in the view layer and populate the messages, it seems > double-handling of exceptions which could be avoided. > > Acegi Security provides a general-purpose ContextHolder and it would > be easy to edit one of the existing filters to pop the Locale into the > ContextHolder on every request. An issue that comes to mind is whether > support should be provided to explicitly change the browser-sourced > Locale via a web controller or filter, or solely rely on the browser > headers. Obviously the latter is simplest, and avoids HttpSession > dependency, at the possible expense of the user experience or > requirements. Spring already has the LocaleResolver mechanism, which is pluggable, with different variations existing, 3 of which fall back to using the locale specified by the request if the main one fails (i.e. there is no cookie, when using the CookieLocaleResolver. I think it makes sense that any scheme which passes a locale down to the service layer ensures that this is, or at least it's possible for it to be, the same locale after as you would get by using the configured LocaleResolver from the web layer. But this actually potentially get's tweaked by the web controller itself (by calling setLocal() for example). This is why I suggested that what gets bound (in one variation at least) is actually an object holding and delegating to the real LocaleResolver and the request. This could then be bound conveniently (for Spring MVC) via a HandlerInterceptor. For the non-Spring MVC case you would probably do it via a generic servlet filter, which binds an object supporting the same interface (LocaleAccessor?). Even in that case there could be a real LocaleResolver and request backing it, or alternately something more static... > > Another issue to consider is the integration with rich clients. It's > often fairly easy to pass a general-purpose Context (or its core > contents) from a rich client tier to a services tier. For example, > Acegi Security provides automatic propagation of the ContextHolder > contents for RMI invocations (so the Locale could traverse the tiers) > and automatic propagation of the username and password in the > ContextHolder for HttpInvoker invocations (which could easily be > extended to obtain the Locale and set the necessary HTTP headers > accordingly). > > IMHO developing a general-purpose Context for authentication and > locale resolution therefore could be useful addition. If this were to > happen, I would encourage Context management become part of Spring > Core so that its MVC classes and remoting classes in particular could > offer fuller integration. The existing Acegi Security context model > might provide some starting point (see class diagram at > http://acegisecurity.sourceforge.net/docbook/Context.gif). I would > happily change Acegi Security to support a Spring Core based user > context management approach. I think this makes some sense. This is why I mentioned the Acegi Security stuff... |
|
From: Tim K. <tim...@vi...> - 2004-12-06 16:13:24
|
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 > |
