http://bugzilla.slf4j.org/show_bug.cgi?id=116
--- Comment #25 from Joern Huxhorn <[EMAIL PROTECTED]> 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. _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
