[slf4j-dev] Structured data "was Plan for SLF4J 2.0"

[Ceki Gülcü]

On 10/03/2010 2:41 AM, Ralph Goers wrote:
> I am extremely tired of this discussion.

I am sorry to hear that. Do you feel that your arguments are not being
heard properly? Or do you think that the matter under discussion
admits such an obvious solution that it does not merit debate?

More below.

> On Mar 9, 2010, at 10:08 AM, Ceki Gülcü wrote:

>> Let's say you have a parameter of type 'House' you would like to log
>> and you wrap it inside a new type called StructuredDataHouse and pass
>> it to a logger as the first parameter (the message being "{}").
>
 > You can't do that on a LocationAwareLogger so this is impossible
 > with any Logger implementation based on LoggerWrapper.

It's not the logger which wraps House but the user. The location of
the logger call remains unchanged by the wrapping which is there for
encoding purposes only. Here is an example:

   StructuredDataHouse  sdh = new StructuredDataHouse(house);
   logger.info("{}", sdh);


If this encoding thing catches on, we could dispense with the wrapping
thing altogether. You could register an RFC5424 "subencoder" for the
House type and the RFC5424Encoder would look it up at runtime.

So you could just write:

   logger.info("{}", house);

The RFC5424 encoder and the transformer for House would just output the correct 
information.

>> The
>> RFC5424Encoder detects that this parameter supports RFC5424 encoding
>> and asks StructuredDataHouse for its RFC5424 encoded
>> data. RFC5424Encoder only neeeds to deals with objects supporting
>> RFC5424 encoding, there is no need to anticipate other encoding types.

 > 1. You can have a bunch of parameters. The encoder has to check
 > every one of them.

Yes, but that's just iterating over the parameters.

 > 2. I guess you'd also have to be able to configure a whole list of
 > encoders and run through all of them to make sure each of your
 > parameters was formatted correctly, even if the message doesn't
 > contain data matching any of them.

Well, the encoder is unique per appender. However, as discussed above
there might be subencoder specific for each type you care about. For
types without sub-encoders, some default heuristic would be applied which I 
already mentioned.

>> The end result is very similar to asking your StructuredDataMessage in
>> the org.slf4j.message package for its formatted message, except that
>> the question is asked by a RFC5424Encoder. A different encoder would
>> ask a different question.

 > This is not similar at all. The layout/encoder/whatever calls
 > getFormattedMessage and gets an appropriate response. Since everything
 > is a Message the method is always there.

How is this different than toString()? Everything is an object and the
toString() method is always there.

--
Ceki