MessageSourceAccessor limitations (or, ThreadLocal locale?)

[shaug]

I'm in the process of incorporating i18n features into our product, and was intrigued to see ApplicationObjectSupport and its built-in getMessageSourceAccessor() method. However, the utility of this method seems artificially limited, due to the limitations of the MessageSourceAccessor object itself.

Once a MessageSourceAccessor is created, there is no way to change its underlying locale. This wouldn't be much of an issue, if the MessageSourceAccessor is created accurately to begin with.

But unless I'm reading the code wrong, the MessageSourceAccessor returned by getMessageSourceAccessor always uses Locale.getLocale() as its locale, if not specified in the constructor. And since the ApplicationObjectSupport doesn't have access to the request's locale, it has to use this constructor. Thus, this method becomes useless for doing any actual locale-sensitive message retrieval.

Of course, I'm not obligated to use this method and its resulting object. But it's built in to pretty much every spring web object (and, thus, most of my web objects), and it would be nice to take advantage of this ubiquity rather than having to make every class that needs this functionality MessageSourceAware and handling it thusly.

What would be nice is if the MessageSourceAccessor would allow its locale to be changed. What would be even nicer is if the Locale were added to the ThreadLocal object, like the transaction objects. Once the DispatcherServlet has determined the locale, it could add it to the ThreadLocal object. Then the MessageSourceAccessor could rely on this Locale if available. If it's not there, then it could rely on Locale.getLocale().

I was going to file this as a bug (maybe even with a patch!), but I wanted to (hopefully) discuss it in the forums first to make sure I'm not missing something important, which I do quite frequently. Perhaps there's a very good reason why the Locale shouldn't be ThreadLocal; if so, please smack me down accordingly.

[Colin Sampaleanu]

All the MessageSourceAccessor methods have a variant which takes a locale. The presumption right now is that if you care about the locale, you use those variants.

That is, you use something like LocaleChangeInterceptor or whatever mechanism makes sense to set the current locale on each request. View code typically uses RequestContext.getMessage to get messages in the proper locale without worrying about things. Controller code when working with the BindException 'errors' object doesn't have to worry about the locale either as that is handled for the view. But other controller code that needs to get messages does have to use something like RequestContextUtils.getLocale() to get the current locale, and supply it as the locale when resolving these messages. Additionally, any other objects that extend from ApplicationObjectSupport and use the supplied MessageSourceAccessor have to get the locale from somewhere (not-determined) if they want to override the default locale...

I agree that the idea of binding the current locale to a thread be used as the default locale by MessageSourceAccesor would probably make some sense, for use in the last two cases above.

Can you file a JIRA enhancement request?

[Colin Sampaleanu]

Nobody ever appears to have filed an enhancement request for this. I made one a few days ago as:
http://opensource.atlassian.com/proj...browse/SPR-485

I'm not sure this will actually get done for 1.1.3 though...