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

[Ralph Goers]

I am extremely tired of this discussion.

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

> On 09/03/2010 5:42 PM, Ralph Goers wrote:
>> 
>> On Mar 9, 2010, at 6:55 AM, Ceki Gülcü wrote:
>> 
>>> 
>>> Once you have a custom encoder, you can encode parameters as you see
>>> fit. This of course assumes logback as the slf4j backend since
>>> encoders exists only in logback. Given that parameters are passed to
>>> appenders unaltered from slf4j to logback, I don't think I am ignoring
>>> the question of getting the data to the appender, or am I?
> 
> > Yes, you are. If you look at RFC 5424 you will see that it supports
> > structured data elements inside an element id. The spec also supports
> > multiple of these. By its nature, the MDC can already be wrapped in a
> > structured element but other things cannot. They are just arbitrary
> > parameters. It is possible that I might want to have two structured
> > data sections in the output. With a Message this can easily be
> > accomodated by creating a new Message class where getFormattedMessage
> > knows that it will contain an array of StructuredDataMessages and will
> > then format it accordingly.  This can be done for virtually any object
> > type. Having to do this with an encoder or layout means writing a lot
> > of ugly code that tries to anticipate all the various objects that
> > might get passed in.
> 
> 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.

> 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.
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.

> 
> 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.


> 
>>> Assuming the parameters get to the appender unaltered, an
>>> RFC5424Encoder could ask each parameter whether it can be encoded in
>>> RFC5424. If the argument supports RFC5424 encoding we would use the
>>> data supplied by the argument itself. Otherwise, we would use the
>>> value returned by toString() and prepend the key "argN=" for argument
>>> N as its generic RFC5424 encoding.
>> 
>> This is exactly my point. This sucks.
> 
> What sucks? It seems to me that such heuristic already provides better
> support for structured data then a *general* message type. If you are
> passed an object whose getFormatedMessage returns an arbitrary result,
> you would need some way of ensuring that it plays nicely with the
> RFC5424 format. The heuristic above provides a way.

Sure, I can still do if (Message instanceof StructuredDataMessage) to make sure it is valid if I want to. In lots of cases you won't care. The layout will just call getFormattedString and accept what it gets back.

> 
>>> For Object serialization which is another form of encoding, an Object
>>> encoder would ignore the RFC5424 capabilities of parameters and use
>>> serialization instead.
>>> 
>>> It seems that postponing the decision to transform an argument to its
>>> desired encoding up until the last minute without imposing a type is
>>> actually a pretty good design.
> 
> > It is a good design for the overall layout. It is not a good design
> > for formatting the objects where the objects themselves can do the
> > formatting.  With a slightly smarter method in the Message interface
> > it is possible that the Message could even format itself based upon
> > information passed from the layout/encoder.
> 
> What I am proposing still uses the formatting capabilities of each
> object, but it does so in a targeted way. If an object supports both X
> and Y encoding, an X-encoder would use the object's X-encoding
> capabilities whereas a Y-encoder would use the object's Y-encoding
> capabilities.

The Message concept is much simpler, much clearer, and much cleaner with a lot less ambiguity. As soon as Joern proposed it instead of what I originally had to do I realized how much cleaner and simpler it actually is. Because SLF4J/Logback doesn't support this stuff I had to implement my RFC 5424 support in my own source control based on the XML serialized EventData. It is error prone since the data might not be a serialized EventData object. Even if I could get it as a parameter, checking each parameter is painful.

Ralph