[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