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

[Ralph Goers]

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.

> 
> 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.
> 
> 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.
 
> 
> I have not coded any of this so it may all be a pile of vaporware crap.

I have. Several times. What Joern proposed works very well and is the model I am following for Log4j 2.0. The version on my slf4j/logback branch works and is binary compatible with current SLF4J versions but isn't as straightforward.

Ralph