[logback-dev] MessageFormatter

[Ralph Goers]

FWIW, I've implemented Joern's proposal at http://github.com/rgoers/slf4j and http://github.com/rgoers/logback. The impact on SLF4J is minimal. In SLF4J I added a message package where the support is encapsulated. Since Logback's client API is SLF4J the new methods have to be implemented there. The overhead of doing this is negligable.  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.

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. The EventData I added to slf4j-ext was a first stab at this (before I knew RFC 5424 existed), but it is very costly since SLF4J doesn't support passing an Object through LocationAwareLogger. In addition, logback-classic isn't dependent on slf4j-ext so adding support for EventData would introduce an undesirable new dependency. 

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. 

Ralph



On Jan 20, 2010, at 8:33 AM, Rü wrote:

> 
> Hi Joern,
> 
> 
> Joern Huxhorn-2 wrote:
>> 
>> It's possible to provide the new API by wrapping the old one (I've
>> prepared exactly that already) but implementing it "natively" would enable
>> Appenders (in case of Logback) to work on Messages instead of Strings,
>> opening up lots of new opportunities.
>> 
> 
> I was very well aware of your point. I just would prefer to leave SLF4J more
> or less as it is (only tiny steps like binary compatible varargs, like Ceki
> had suggested) and put your API into a separate package. I think it's a too
> different use case and a too fast pace for the core logging API that SLF4J
> is becomming. Your new API could be implemented natively e.g. by Logback or
> as a wrapper for other logging systems.
> 
> As I've said: I can see the great benefit of such an API. We actually use
> the Logging-APIs to inform monitoring tools e.g. about call latency:
> Something like monitoring.info("{} took {}", system, time); could end up in
> a logfile and/or as a http request for our monitoring framework. We can't
> use Log4j here, as it formats messages before it passes LoggingEvents to
> Appenders and it would be ridiculous to parse the numbers out of the message
> string again. So we switched to Logback ;-) And passing such information as
> structured, eventually typesafe data sounds even better!
> 
> 
> 
>> 
>> Rü wrote:
>>> 
>>> Your warning is legitimate! But I don't want to change the message
>>> format, I want to change the formatter!
>>> 
>> 
>> I think the main problem is that adding such an ability will have an
>> impact on the standard formatter performance.
>> 
> 
> The standard formatter should stay exactly as it is... it should just not be
> one more of those terrible singletons (the modern form of global variables).
> Then I could configure Logback to use one that I write whenever I think I
> can live with the extra performance cost.
> 
> 
> 
>> 
>> 
>>> Put simply, your proposal requires the caller code to change (as well as
>>> SLF4J, Logback, and many others) while my change would work with logging
>>> calls from third party libraries as well ;-)
>>> 
>> 
>> That's not really the case.
>> ...
>> Thoroughly confused? ;)
>> 
> 
> I was talking about third party libraries like Hibernate, that log for
> themselves. When they log objects that've been passed to them, and those
> objects don't know how to String (pun)...... a special MessageFormatter
> could make it readable; but even if Hibernate would pass it's own Message
> object to your API, the objects within would not be formatted to my liking.
> 
> 
> Regards
> Rü
> 
> -- 
> View this message in context: http://old.nabble.com/MessageFormatter-tp27209919p27244635.html
> Sent from the Logback Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev