Internationalizing Strings
Mule supports internationalization of exception messages and any other type of string message.
Internationalized Messages
Mule uses the Java [ResourceBundle] class to load messages from properties files on the classpath based on the current system’s locale.
Mules internationalized messages are represented by the [org.mule.config.i18n.Message] class. Instances are constructed with a message ID and zero or more message parameters. You can see a list of core messages that Mule provides in META-INF/service/org/mule/i18n/core-messages.properties.
You never create instances of Messages directly. Instead, you use subclasses of [MessageFactory]. The messages for Mule’s core project are accessible through [org.mule.config.i18n.CoreMessages] class.
Each of Mule’s modules and transports has such a messages class. Its name is equal to the module with Messages appended. For example, for the JMS transport you will use JMSMessages to retrieve messages.
The dedicated messages class per module/transport has the following advantages:
-
Encapsulation of the message code
-
Client code is not cluttered with
Messageconstructors -
Client code has typesafe access to its messages
-
Client code is not cluttered with formatting of message paramaters. Instead, you handle this in the module-specific messages class.
Exceptions
MuleException is the base class of all Mule checked exceptions and can only be constructed using internationalized messages. To create a message for an exception, you use MuleExtension as follows:
MuleException e = new MuleException(CoreMessages.failedToGetPooledObject());
throw e;Using Custom Message Bundles
When writing Mule extensions or applications that will use Mule internationalized class, you can supply custom message bundles containing messages specific to your extension or application. You create a resource bundle as follows:
1=Error message one
2=Error message with 2 parameters; param {0} and param {1}
...where the number is the message ID and the actual message comes after. Note that message paramemters are specified using '{0}' notation, which is standard when using the Java [MessageFormat] class.
The file should be named x-messages.properties where x is identifying name for this bundle. You must place this file either in your JAR file under META-INF/sevices/org/mule/i18n/x-messages.properties or any other location on the classpath.
To access the messages of your resource bundle, you create a subclass of MessageFactory as follows:
public class MyMessages extends MessageFactory
{
// getBundlePath puts together the correct path (META-INF/services/org/mule/i18n/my-messages.properties)
private static final String BUNDLE_PATH = getBundlePath("my");
public static Message errorMessageOne()
{
return createMessage(BUNDLE_PATH, 1);
}
public static Message anotherErrorMessage(Object param1, Object param2)
{
createMessage(BUNDLE_PATH, 2, param1, param2);
}
}To load a message from this bundle, pass in the resource bundle name as follows:
Message m = MyMessages.anotherErrorMessage("one", "two");
System.out.println(m.toString());This loads the message with ID 2 from x-messages.properties, format the message with the parameters "one" and "two", and prints out the message to System.out as follows:
Error message with 2 parameters; param one and param two