On Feb 21, 2010, at 8:22 PM, Curt Arnold wrote:
>
> 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,
Well, I've finally begun doing some coding this weekend although I haven't
gotten awfully far. I am definitely going to be using the Message interface.
There were some lengthy discussions on the Logback list about this topic and
the problems using an Object introduces for applications like Lillith or
Chainsaw where the Object has to be passed to a remote system. Often
serialization fails miserably and toString often yields unsatisfying results.
It also requires the remote application to have the Classes in the class path
for the objects being sent to it to be able to deserialize the events, which
can be a pain for a general purpose logging reporting application.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
