Acegi internationalization for apps without Spring DispatcherServlet

Acegi by default provides i18n support(For version 1.0.5, it supports Chinese,French, German and English). Unlike specified in the documentation(please read this before reading this post), you don’t need to specify explicit message source, unless you have existing MessageSource defined with id ‘messageSource’ or you need support for additional languages or both, in which case you need to copy acegi related keys from acegis files(which can be found under org.acegisecurity package) to your respective message bundles. AcegiMessageSource takes care of language bundles provided by default.

If you don’t provide message source, acegi classes use AcegiMessageSource through MessageSourceAccessor(Helper class which wraps MessageSource and provides overloaded getMessage methods). If you call one of the getMessage() method on MessageSourceAccessor with out Locale as argument, it tries to get message in default locale provided to it. If default locale is not set, then it tries to get Locale from LocaleContextHolder. But who sets Locale to the LocaleContextHolder? If you are using Spring DispatcherServlet for your requests,a LocaleResolver will do the job for you. For other apps you need to do this before authentication processing filters(For example, AuthenticationProcessingFilter) kicks in. Otherwise i18n won’t work.

In summary, you need to set the Locale to LocaleContextHolder, for apps not using DispatcherServlet, for Acegi’s localization to work. Let me know, if there are any workarounds or I am missing something here.

2 thoughts on “Acegi internationalization for apps without Spring DispatcherServlet

  1. I am using Spring without the DispatcherServlet, and your suggestion worked perfectly…for Acegi.
    A filter (ran before Acegi!) called LocaleContextHolder.setLocale(locale);
    This provided me with internationalized error messages. The tag, however, was not properly localized.

    I have worked around it by setting the fmt attribute (“javax.servlet.jsp.jstl.fmt.locale.request”) with the locale, this works ok. I don’t understand why Spring doesn’t look at the LocaleContextHolder though.

    All using Spring 2.0.8.

  2. The above sentence “The tag, however, was not properly localized.” should have read “The spring:message tag, however, was not properly localized.”.

    I did come across an issue where the fallback to ”javax.servlet.jsp.jstl.fmt.locale is explained.

    Still, why not query the LocaleContextHolder?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s