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.