On 2/20/2010 11:16 AM, Ralph Goers wrote:
One thing I'd like to make sure is not lost is an easy way to pass an Object
rather than a String.
I'd prefer a Message instead of an Object. The primary difference is that the
Message is an interface that looks like:
That initially seems reasonable (though I'm not sure about
getMessageFormat() -- if your formatted message is simple tab delimited
would this then be a string containing 'n' tabs?)
Looking further, though, I'm less certain. For instance, I pass
DynamicMBeans as my message Object in cases. getParameters() could be
expensive here. Instead, my custom appenders are configured with the
list of attributes to obtain in the case of DynamicMBean messages -- so
only those getters are called. getParameters() denies the possibility
of such "just enough" data access.
/**
* An interface for various Message implementations that can be logged.
*/
public interface Message extends Serializable {
/**
* Returns the Message formatted as a String.
* @return The message String.
*/
String getFormattedMessage();
/**
* Returns the format portion of the Message
* @return
*/
String getMessageFormat();
/**
* Returns parameter values, if any.
* @return An array of parameter values or null.
*/
Object[] getParameters();
}
For SLF4J I implemented a ParameterizedMessage (message and parameters), a SimpleMessage (message
string only), and StructuredDataMessage (to support RFC 5424), but all kinds of Message objects
could be created. This makes it easy for appenders and layouts because they just need to call
getFormattedMessage() to include that in the layout, or they can get to the "message" via
getMessageFormat() or the "parameters" via getParameters().
