[slf4j-dev] [Bug 116] Switching the log message format to that of java.util.Formatter

bugzilla-daemon at pixie.qos.ch bugzilla-daemon at pixie.qos.ch
Tue Nov 25 16:22:36 CET 2008


http://bugzilla.slf4j.org/show_bug.cgi?id=116





--- Comment #2 from Grzegorz Borkowski <grzegorzborkowski at o2.pl>  2008-11-25 16:22:36 ---
I also wouldn't like to live with something like that: "%4$2s %3$2s %2$2s
%1$2s" :)

However, please note that this is very extraordinary example: it shows that you
*can* reverse the order of parameters if you *really need*. (In fact
documentation for java.util.Formatter gives you the impression that the simple
things are very complicated). This means it would happen only if you have to
internationalize the existing log messages, without recompiling the code with
fixed parameters order. Normally it would look like this:

"%s %s %s %s"

In other words (I should mention it in the initial post): under normal
conditions the change would be from:

log.debug("some message with param1 {} and param2 {}");

to:

log.debug("some message with param1 %s and param2 %s");

So in fact you replace two-characters-long {} with two-characters-long %s. This
doesn't do much harm from my point of view (though I agree that {} is _a little
bit_ cleaner than %s). The point is however, that you gain really *big*
advantage if you need to have control on formatting of dates or numbers. I
worked on the project when the customer required us to format dates in the log
files the way he decided. It would be probably hard to accomplish with {}
format. We were forced to log every message with the following way: 
log.info(String.format("some message with date-formatted params", arg1, arg2,
arg3);

It would be much cleaner (and efficient if the message is not really going to
be logged) to do it simply this way:
log.info("some message with date-formatted params", arg1, arg2, arg3);


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the slf4j-dev mailing list