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.