Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.7)
  3. Developing
  4. Advanced Usage of Mule ESB

  5. Internationalizing Strings

Internationalizing Strings

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

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. Mule provides a full set of messages in English.

Mule’s 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 Message directly. Instead, you use subclasses of MessageFactory. The messages for Mule’s core project are accessible through the 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 Message constructors

  • Client code has typesafe access to its messages

  • Client code is not cluttered with formatting of message parameters. Instead, you handle tihs 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 the Mule internationalization 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 parameters 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 the identifying name for this bundle. You must place this file either in your JAR file under META-INF/services/org/mule/i18n/x-messages.properties or any other location on the classpath.

To access the messages of your own 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.pritln(m.toString());

This loads the message with ID 2 from x-messages.properties, formats 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

Creating Message Instances from your Code

If you need Message instances from your custom code (e.g., from a custom transformer), you create them as follows:

Message myMessage = MessageFactory.createStaticMessage("Oops");