On 20.01.2010, at 14:36, Rü wrote:
Hi Joern,
Joern Huxhorn-2 wrote:
I'd be happy if you could take a few minutes and check out my proposal.
You where kidding, right?!? "a few minutes"... well, I still did take a look. Nice proposal and it's good to know that there might be some things like that coming. Passing your own Message instances into the API would be powerful and definetely a gain. But I think that's not only an API change, it's a completely different design. I'd say: That's a too big a step for SLF4J to reasonably take. Why not put it into a separate structured logging artifact that wrapps SLF4J.
The original SLF4J API would stay untouched for compatibility reasons. Sorry about the "few minutes" ;) 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.
The impact on performance the wrapping will have is probably in the same range a that you'd introduce by replacing e.g. debug(msg, arg0) with debug(msg, new Object[] { arg0 }) by only using varargs... hotspot is really smart, you know?
For the varargs discussion, I like Cekis suggestion http://bugzilla.slf4j.org/show_bug.cgi?id=31#c31 31-31 best.
That comment refers to a previous proposal that merely changed the Object[] into Object... I've instead added a new, additional API that you can either use instead of the old one or ignore. This has the advantage that projects requiring JDK1.4 could still be supported.
Changing the default message format (or making it configurable) of Logback, on the other hand, isn't a good idea since the contract of it is derived from SLF4J. Any SLF4J implementation must be able to support the new formatting.
Your warning is legitimate! But I don't want to change the message format, I want to change the formatter! I don't want to e.g. put extra stuff within the curly bracket placeholders, generally preventing other SLF4J implementations from working properly. But I do want to change what goes in there. I.e. when I want to log a message with an argument that's an instance of a class that doesn't override toString to my liking (most notably: not at all), I want to provide my own formatter for all instances of that class. Anything else would be my own risk... if I'd ever choose to go away from logback, that is ;)
I think the main problem is that adding such an ability will have an impact on the standard formatter performance. Additional lookup is needed to check if a special formatter is registered - for every parameter. I don't say that this will be terribly expensive but a certain cost will be created.
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. You can either leave everything as it is right now, since SLF4J API would stay binary-compatible, or switch to the new API by simply changing the import of Logger and LoggerFactory. This can easily be done by a quick search & destroy/replace. The same is the case for third-party libraries/implementations of SLF4J other than Logback. They will still work as before, even if the new API is used, since the original SLF4J would simply be wrapped. In case of a more modern implementation that natively implements the new SLF4J API, the old API would be implemented by wrapping the new API. Thoroughly confused? ;) Regards, Jörn.
Regards Rü -- View this message in context: http://old.nabble.com/MessageFormatter-tp27209919p27241839.html Sent from the Logback Dev mailing list archive at Nabble.com.
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev