Mule

Internationalisation support for Mule messages and exception messages.

The `Message` class is a wrapper for an error message, its error code and other information. The messages are read from `ResourceBundle`s usually from classpath.

The class `MessageFactory` encapsulates the lookup of `ResourceBundle`s and creation of messages. Since each mule module should provide its own messages, subclasses of `MessageFactory` should be created. It is convention to put the module specific class in a subpackage called `i18n`.

### Subclassing MessageFactory

For a mule module foo with base package `org.mule.module.foo` a MessageFactory subclass would typcially look like this:

    package org.mule.module.foo.i18n;

    public class FooMessages extends MessageFactory
    {
        private static final String BUNDLE_PATH = getBundlePath("foo");

        public static final Message foo()
        {
            return createMessage(BUNDLE_PATH, 1);
        }

        public static final Message bar(String arg)
        {
            return createMessage(BUNDLE_PATH, 2, arg);
        }

        .
        .
        .
    }

Note that the only publicly available methods are those from `FooMessages`. This approach has various advantages:

- `Message` instances are created using meaningful java methods, i.e. client code is less cluttered with message cration details.
- The method signature ensures that the right number of arguments is passed in to format the message.
- No more constants for message codes needed as there is exactly one occurrence of the constant in the code.
- By using the right `MessageFactory` subclass it is ensured that the correct `ResourceBundle` will be chosen for lookup.
- Formatting the input to messages can be taken out of the client code by putting it in this class