The Solution
When the challenges were completely understood, it was decided that a custom Locale and a custom Resource bundle should be used while providing a solution. The custom Resource bundle will be more like a property resource bundle, in which case a key will be used to retrieve a corresponding value based on the custom Locale. Since this custom resource bundle was expected to be CMA database-centric, essentially the key will be an index into the content in the CMA database supplemented by a custom locale.

The foremost thing we ensured was that the underlying CMA database schema supported retrieval of content based on a content key and a custom locale. The existing CMA database schema did not fully support what we were looking for in terms of a content key. We had to come up with extensions without disturbing other parts of the schema so that localized content could be retrieved by using a unique content key. Based on these extensions, the CMA UI interface was also modified to provide the ability to create content with a unique content key in multiple different languages and the ability to target the content to a particular locale. Figure 6 is a simplified view of the extensions made to the schema with the existing design constraints in place.

The custom implementation of the database-centric Resource bundle was pretty straightforward. The custom Resource bundle class "DynaResourceBundle" was created by extending java.util.ResourceBundle and by overriding the "handleGetObject" method. The "handleGetObject" method is called internally when either the "getString" or the "getObject" method of the Resource bundle is invoked. An instance of this class will be created by passing the custom locale and a String array containing resource names. A constant resource name "CMAX" was used to indicate to the bundle to pull content from the underlying CMA database. All other resource names were considered as non-CMA resources. For all non-CMA resources, the usual ResourceBundle.getBundle method was first used to load the bundle using the resource name and the current locale, and then the content value was retrieved using the key. The resources are tried out in the order they are found in the array while retrieving the content. If the current resource in the array returns null, then the next resource is used to retrieve the content. This is a simple failover approach in case content is not found in one resource. Listing 1 shows the concrete implementation of this method.

Please note that "Label" is a data object representing a label entry in the CMA database. The "handleGetObject" method internally uses a "ContentBO" instance while retrieving content from CMA. The "ContentBO" is a content retrieval business helper object that actually interacts with the data access objects to retrieve content from CMA. The "ContentBO" provides a "getLabel" method that looks up a "DAOFactory" class to get a reference to the DAO implementation for labels and invokes the "getContent" method on the DAO by passing the content key and the locale. The "ContentBO" also has a static method - "getFallBackLocales" - that implements the business requirement for the content look-up fallback logic approach as described earlier. It turns out that this requirement translates into the fallback of custom locales in our design and fits well with the approach we took. So ultimately our choice of the custom locale with "site name" as a variant paid rich dividends. Listing 2 is a code snippet for the "getLabel" method in the ContentBO object.

The "LabelDAO" class is extended out of an abstract DAO class and provides the concrete implementation for retrieving the content from the database. This class implements the "getContent" method; the content key and the custom locale are the arguments to this method.

class LabelDAO extends AbstractDAO {
public CMAObject getContent( String contentKey, Locale locale ) throws SQLException{
     .......
}
}

Note that this class has package-level access in the package "com.ual.i18n.content.dao" since an instance of this class is actually created by the DAOFactory that is part of the same package. The method "getContent" simply retrieves the language, country, and site name from the locale object, builds the SQL using the content key, and executes the SQL to retrieve the label from the CMA database. Listing 3 shows a code snippet from the method "getContent."

Once the text of the label is retrieved from the database, this method invokes the inherited method "getEncodedText" by passing the retrieved text and "UTF-8" as the character set encoding. The following code snippet is for the "getEncodedText" method defined in the "AbstractDAO" class:

public String getEncodedText
( String text, String encoding ) throws UnsupportedEncodingException {
		if( text == null ){
			return null;
		}

		String encodedText = new String( text.getBytes( "8859_1" ), encoding  );

		return encodedText;
	}

Figure 7 summarizes the method calls required to retrieve a localized label from the "DynaResourceBundle" class while retrieving the content from a CMA database.

Internationalization with Struts
As expected, Struts internationalization support is based on use of Locale class and Resource bundles. However, Struts slightly differs in terms of handling resource bundles. Struts uses the "MessageResources" class and its sub class "PropertyMessageResources" in the "org.apache.struts.util" package to represent resource bundles. Even though Struts web application developers normally do not directly work with an instance of "MessageResources," it provides an API to retrieve localized messages. Struts uses this API internally to provide appropriate messages to the framework clients. One of the reasons why Struts uses message resources to represent resource bundles is because Java's resource bundles are not serializable and Struts wanted to create its own serializable representations. Struts requires that any object it manages internally be serializable because a Struts-based Web application can be deployed in a clustered server environment where session data replication could be enabled.

The big question at that point was how to make our own custom resource bundle "DynaResourceBundle" work with Struts in a way that is transparent to the rest of the application. After much research, we could not find a direct way of incorporating "DynaResourceBundle" in Struts. We had to look into other options. Typically, Struts looks up the following configuration in the struts-config.xml to load an instance of the "MessageResources" class representing an "application.properties" file and retains it in memory for the life of the application.

<message-resources parameter="application" null="false" />

The promise of Struts has always been to enable the incorporation of custom "MessageResources" implementations that retrieve data from other sources such as a database. With this promise in mind, we moved forward with the idea of extending the "MessageResources" class in such a way that we could glue our custom resource bundle to the Struts framework. We created a custom class - "DynaMessageResources" - by extending "MessageResources" as shown in Listing 4.

The main methods that are overridden are the "getMessage" methods. The method that is internally called by the Struts framework is the overloaded "getMessage" method that takes locale, key, and an array of objects. The array of objects is typically passed to this method to replace indexed parameters in the actual messages. The indexed parameters ({0}, {1}) are placeholders in a message that can be replaced at run time with certain values.

The MessageResources class internally uses the "java.text.MessageFormat" class to format messages with run-time values. The MessageResources class provides a default implementation for the "getMessage" method with three arguments; however, one word of caution about this method: it caches the message format objects for each message in a local HashMap for the life of the application. This may prove to be undesirable if the custom message resources class is not supposed to cache because either there is no requirement to cache any messages or caching could be done outside of this class with much more control to refresh the cache on demand. This was the main reason why we had to override that method by eliminating the need to cache the message format objects in a local HashMap. However, the core function of the method was not taken away in the sense that it still performed formatting of the messages using the MessageFormat objects but without caching them. Note that this method internally calls the other overloaded method "getMessage" that takes two arguments: locale and the message key.