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

[bugzilla-daemon at pixie.qos.ch]

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





--- Comment #25 from Joern Huxhorn <joern at huxhorn.de>  2008-12-04 11:05:22 ---
Something like

Logger logger = FormatModifyingLoggerFactory.getLogger(this.getClass(), new
JavaUtilFormattingFormatModifier())

would solve the immediate requirement of using java.text.MessageFormat for log
messages but it doesn't solve the problem of internationalizing messages, it
even prevents a solution to that problem.

The problem with this solution is that it's putting the responsibility of
message formatting into the frontend (i.e. Logger) instead of the backend (in
case of Logback - the appenders).

At the moment, it's entirely undefined which part of the logging framework will
ultimately perform the formatting of the message and at what time, exactly.

The current version of Logback formats the message lazily and serializes the
unformatted message instead of the formatted one, along with the arguments
converted to String.

Using functionality like the one above would change that freedom and would
require the replacement of the unformatted message of the event with the
formatted one because, after deserialization (to be more precise, most likely
directly after logging event creation), the information about the formatter to
use would be lost.

This would imply that the suggestion I made in comment 1 about localization of
log messages wouldn't be possible anymore because the unformatted message
pattern (the localization key, in my example) is lost forever.

Instead, I'd suggest to keep everything as it is right now, at least on the
SLF4J-side of logging.

If handling of arguments beyond MessagFormatters string conversion is needed it
should be enclosed in respective isXXXEnabled() blocks. That's OK, IMHO,
because it is a very, very special case.
I've hardly had one of those situations and the places where I did something
like that could now be simplified because MessageFormatter is now handling
arrays in a nice way, too.
The remaining specifically formatted log messages are formatted in a very
specific way that could not be handled by java.text.MessageFormat anyway.

By putting the burden of message localization on the backend (Logback)instead
of the frontend (slf4j) we get some nice additional possibilities:

- the way it would actually be done would be interchangeable.
- there is always a properly formatted message available as a fallback even if
there is no translation available: the message created using the "normal"
message formatting.
- the same logging event could be displayed to different users in different
languages.
- most importantly, any message logged using slf4j could be localized instead
of only the ones that use the special logger. 
To emphasize: This means that logging of any third-party library could be
localized!

As far as I can tell, the single entry-point for a functionality like the one I
described in #1 would be ch.qos.logback.classic.pattern.MessageConverter in
case of Logback.

It would have to be configurable somehow instead of just returning
event.getFormattedMessage(). This could be done using a System property but
this implementation detail isn't important right now.

My main point is that this whole discussion should be moved over to Logback
because it's essentially an issue of working with the already generated event
and not an issue of the logging frontend, i.e. SLF4j.


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