Once you have a custom encoder, you can encode parameters as you see
fit. This of course assumes logback as the slf4j backend since
encoders exists only in logback. Given that parameters are passed to
appenders unaltered from slf4j to logback, I don't think I am ignoring
the question of getting the data to the appender, or am I?
Assuming the parameters get to the appender unaltered, an
RFC5424Encoder could ask each parameter whether it can be encoded in
RFC5424. If the argument supports RFC5424 encoding we would use the
data supplied by the argument itself. Otherwise, we would use the
value returned by toString() and prepend the key "argN=" for argument
N as its generic RFC5424 encoding.
For Object serialization which is another form of encoding, an Object
encoder would ignore the RFC5424 capabilities of parameters and use
serialization instead.
It seems that postponing the decision to transform an argument to its
desired encoding up until the last minute without imposing a type is
actually a pretty good design.
I have not coded any of this so it may all be a pile of vaporware crap.
On 09/03/2010 3:19 PM, Ralph Goers wrote:
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
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
