Hi Ralph, I thought that you'd be the second one to reply ;-))) rgoers wrote:
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. Regards Rü -- View this message in context: http://old.nabble.com/MessageFormatter-tp27209919p27257209.html Sent from the Logback Dev mailing list archive at Nabble.com.