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
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
