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 ResourceBundles
usually from classpath.
The class MessageFactory encapsulates the lookup of
ResourceBundles 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
|