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

[Ceki Gülcü]

On 09/03/2010 11:45 AM, Joern Huxhorn wrote:
 >
 > What would it take to convince you?
 >
 > The addition of Message support would solve problems like the following
 > in an unintrusive
 > http://bugzilla.slf4j.org/show_bug.cgi?id=116 (java.util.Formatter support)
 > http://bugzilla.slf4j.org/show_bug.cgi?id=148 (StructuredData support,
 > RFC 5424)
 > http://jira.qos.ch/browse/LBCLASSIC-76 (Allow extension of LoggingEvent
 > with new data)

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?

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

or

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

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:

class  MesssageLogger {

   Logger logger;

   void debug(Message msg) {
     logger.debug("{}", msg);
   }
   ...
}

BTW, I've started looking at both Ralph and Joern's proposals.

--
Ceki