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