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

Ralph Goers rgoers at apache.org
Tue Mar 9 15:19:39 CET 2010


On Mar 9, 2010, at 5:29 AM, Ceki Gülcü wrote:

> 
> 
> Well, I haven't yet come across a convincing use case or maybe I have
> but failed to grasp its significance. Anyway, it seems to me that RFC
> 5424 defines a text-based encoding scheme more than anything else. It
> follows that RFC 5424 could be supported by logback simply by
> composing FileAppender with an appropriate encoder, say
> RFC5424Encoder. Encoders are new in 0.9.19. This encoder could not
> only encode the contents of the message but other logging event fields
> such as time, logger, level as well which is probably what you really
> want. Does the RFC5424Encoder make sense?

Absolutely not. The problem you are ignoring is getting the data to the Appender in the first place. That is why a Message is required. Remember, this is "Structured" data. To be structured you have to have a structure, not a message and a bunch of parameters.  Whether the formatted string is created by a Layout or Encoder is somewhat irrelevant.

> 
> Regarding the encoding of the message contents, I think it can be
> addressed by convention:
> 
> 1) message parameter implements some well known interface, say
> RFC4224Aware

If you go down this road then you have to start inspecting all the parameters for the interfaces they implement. I started with this. It is awful.

> 
> or
> 
> 2) message parameter implements some well known method "toRFC5424():
> String""

Not a whole lot better. Joern's proposal of having the Message delegates to the Message object instead of having Appenders try to support all the various interfaces that might exist.

> 
> Given that SLF4J already allows you to write
>   logger.debug("{}", myRFC5424AwareData);
> putting aside the issue location awareness, I fail to see the point of
> changing the org.slf4j.Logger interface to add support for
> typed-messages especially considering that one can easily write an
> SLF4J-extension with the appropriate syntactical sugar:

Because the proposals above really suck. It is more or less what I was forced to do to support EventData and the performance isn't that great.

Ralph



More information about the slf4j-dev mailing list