The SpringModules cache extension provides the legwork for implementing this and Spring AOP the glue. One limitation of this implementation out of the box is that it is not Locale aware. Spring nicely provides a LocaleContextHolder to enable disparate components within the app stack to be locale aware so we needed to leverage this in order to ensure our method caching was able to not only cache method invocations with the same argument signature, but also within the same Locale (not something passed as arguments) .

Below is the meat of our simple solution, a LocaleAwareCacheKeyGenerator:

    public final Serializable generateKey(MethodInvocation methodInvocation) {

        Method method = methodInvocation.getMethod();

        HashCodeCalculator hashCodeCalculator = new HashCodeCalculator();
        hashCodeCalculator.append(method.hashCode());

        // now suck in the locale
        Locale locale = LocaleContextHolder.getLocale();

        // and use the bit we care about for hashcode generation
        if (considerLanguageOnly) {
            hashCodeCalculator.append(locale.getLanguage().hashCode());
        } else {
            hashCodeCalculator.append(locale.hashCode());
        }

        // now try and sort out things for the method args
        Object[] methodArguments = methodInvocation.getArguments();

        if (methodArguments != null) {
            int methodArgumentCount = methodArguments.length;

            for (int i = 0; i < methodArgumentCount; i++) {
                Object methodArgument = methodArguments[i];
                int hash = 0;

                if (generateArgumentHashCode) {
                    hash = Reflections.reflectionHashCode(methodArgument);
                } else {
                    hash = Objects.nullSafeHashCode(methodArgument);
                }

                hashCodeCalculator.append(hash);
            }
        }

        return new HashCodeCacheKey(hashCodeCalculator.getCheckSum(), hashCodeCalculator.getHashCode());
    }

This class simply adds the Locale to the code used in the HashCodeChacheKeyGenerator supplied with Spring. So now we can easily enable locale aware AOP configured method invocation caching transparently to our application code.

Nice!

P.S. An eclipse project with code/test samples is available

One thing that we wanted to do was have themes which override certain resource bundle variables defined in an application wide, internationalized properties file. For example, our login greeting is “Welcome” with an appropriate i18n version for various locales. We also have certain themes based on types of user accounts. Some themes require their own customized login greeting and others will rely on using messages from the default MessageSource.

Our Spring application utilizes two classes for accessing resource bundles:

• org.springframework.context.support.ResourceBundleMessageSource
• org.springframework.ui.context.support.ResourceBundleThemeSource

Both these classes provide access to specific resource bundles but do not necessarily know about each other which means the operate in isolation. Ideally we wanted to have a hierarchy of resource bundles such that a resource message defined in the bundle accessed by ResourceBundleMessageSource could be overridden by a message defined in resource bundles accessed by ResourceBundleThemeSource. Whilst the ResourceBundleMessageSource class has a setParentResourceBundle(), there is no way to inject that to the ResourceBundleThemeSource via configuration.

As the resourceful (no pun intended) java developers that we are, we decided to create our own wrapper class for theme bundle resolution. This class will use the application’s ResourceBundleMessageSource definition as a parent for its own resource message source so that we can ensure that if a message cannot be resolved by key in the theme bundle, it will then defer to the parent resource bundle (which is the application level MessageSource) and try and look up the key there. This simple class is outlined below:

public class CustomResourceBundleThemeSource
        extends ResourceBundleThemeSource {

    private MessageSource parent;

    public void setParentMessageSource(MessageSource messageSource) {
        parent = messageSource;
    }

    @Override
    protected MessageSource createMessageSource(String basename) {
        ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
        messageSource.setBasename(basename);
        messageSource.setUseCodeAsDefaultMessage(true);
        messageSource.setParentMessageSource(parent);
        return messageSource;
    }
}

With this class, we just need the following in our Spring config class:

    <bean id="messageSource"
          class="org.springframework.context.support.ResourceBundleMessageSource">
        <property name="basenames">
            <list>
                <value>bundles/messages</value>
            </list>
        </property>
    </bean>
    <bean id="themeSource"
          class="CustomResourceBundleThemeSource">
        <property name="basenamePrefix" value="/themes/" />
        <property name="parentMessageSource" ref="messageSource" />
    </bean>

Now whenever we need to resolve resource messages, we use the Spring specific theme tags:

    <spring:theme code="login.greeting" />

And if we have a definition in our theme resource bundle we see that else we see the default definition as specified in the underlying MessageSource.

This allows us to override resource bundle messages for various themes as required and removed quite a bit of ugly JSP/JSTL logic for resolving messages conditionally.

Job done.

There are many ways to to provide runtime configurations for Java applications. For web applications, two popular mechanisms are the use JNDI configurations managers and using properties files. Both mechanisms have their limitations and caveats.

When using The Spring Framework, we are presented with a few more options to enable configuring web app projects.

The traditional approach involves using property placeholders which are then munged at runtime with a specific properties file to ensure the placeholders have valid values before executing the application. Another approach is using the newer (Spring 2.0) PropertOverrideConfigurer to override pbean definition properties at application startup. This approach allows the default spring config file to be usuable w/out needing a valid property file as no placeholders exist in the config itself but properties are merely overridden at runtime if need be. This is slightly nicer as it means that a default spring context XML config file will run w/out needing any special property merging. This allows for projects to be run within an IDE (like Eclipse) without having to jump through hoops or run special ant/maven targets to stick the correct properties file in the classpath when wanting to run your app embedded in Eclipse.

Essentially, the default Spring context configuration will work out of the box but can be overridden at runtime with other property file based properties to ensure things run properly at deployment. It’s not that dissimilar to the PropertPlaceholderConfigurer but allows for an easier workflow when wishing to work seamlessly with an IDE.

Not sure if any of this makes sense but there is more info out on the InterWeb:

• PropertyOverrideConfigurer
• configuration-management-with-spring