ruediger.dohna at 1und1.de
Thu Jan 21 13:52:58 CET 2010
I thought that you'd be the second one to reply ;-)))
> In reality this is the only good way to do what you are asking for. As
> Ceki has pointed out, changing the message formatting for a "standard"
> message creates endless problems since many components all use the the
> SLF4J api and expect the current formatting. Joern's proposal, where the
> formatting is dictated by the message type provides the required
> flexibility in a much more deterministic manner.
I don't want to change the format strings in my log statements!!! I don't
want to change what's going in, just what's going out!!! Nobody relies on
that. I am free to write any Layout I like. For example in version 0.9.18
the EchoLayout just uses toString and not event.getFormattedMessage().
LoggingEvent.toString luckily calls event.getFormattedMessage() itself, but
LoggingEventVO doesn't even override toString(). You could argue that this
is a bug, but: What contract is broken?!? I could even write my own SLF4J
implementation that completely ignores the formatting anchors and just
appends the arguments with a fixed delimiter... no contract broken! Only
when I start to omit the formatting anchors, then I'm breaking the SLF4J
contract... I can't switch to another implementation any more. Same thing,
when I start to add some kind of formatting instructions into the formatting
anchor: Broke the SLF4J contract and can't switch any more.
> We are using SLF4J/Logback for Audit/Event/Activity logging. Structured
> data is a perfect fit for that use case. Not having that available in
> SLF4J makes audit logging difficult.
We have this use case, too, but it is a different use case! I need to simply
format objects that anyone (maybe even Hibernate) tries to log.
> Finally, RFC 5424 is the new syslog spec. I have recently completed a
> review of all the commercial log management products, such as ArcSight,
> Splunk, SenSage, LogLogic, etc and they all support this format, as do
> syslog-ng and rsyslog. So I view SLF4J/Logback not supporting this format
> as a serious deficiency.
Is this review available anywhere... we have similar discussions with our
system admins. Would be helpful to have more fuel ;-))) And structured
messages would be great to store into the database, too!
But it's again two use cases: Either you want to put structured data into
your logging api, or you want to put structured data out onto the channel.
The full power would only unfold, if you have both, of course! But the other
combinations make sense in their own right.
View this message in context: http://old.nabble.com/MessageFormatter-tp27209919p27257209.html
Sent from the Logback Dev mailing list archive at Nabble.com.
More information about the logback-dev