On Feb 20, 2010, at 11:16 AM, Ralph Goers wrote:
>
> I'd prefer a Message instead of an Object. The primary difference is that the
> Message is an interface that looks like:
>
> /**
> * 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().
>
> Ralph
>
I'd expect that parameterized log requests would end up packing the format
string and parameters into an object for evaluation in the extraction phase.
There are two different formatters in the Java library in addition to the SLF4J
formatter, so if you were interested in making sense of the format string,
you'd need to do an instanceof to determine which formatter was being used.
I'm thinking it is best just to rely on Object.toString() to get the formatted
string, If something in the stack wants to do something funky with the message
format string or parameters, they can use instanceof to cast to a specific
class.
We'd likely end up with an ParameterizedMessage interface with the
getParameters() method and then concrete classes for the
SimpleFormatParameterizedMessage, MessageFormatParameterizedMessage,
FormatterParameterizedMessage, et al. I'd definitely like to stay using Object
for the message parameter in the core until there is a clear benefit to being
more restrictive. Should make it easier to support log4j's lack of
restriction on the message parameter if we don't have to repackage it as a
single parameter parameterized message,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
