Ralph Goers wrote:
* The provision of the Locale should be an orthogonal concept to the
logging of messages and the creation of the Logger. This should be
handled via the MDC.
"could be handled via the MDC". There are other ways to do it but that
is probably the simplest.
Pushing the locale in every thread will not suite everyone.
IMO there are still a few questions to answer:
* Takeshi original design allowed you to use Enums as keys for
messages. I'm personally not sure about this, I'm not really sure what
benefits it offers over Strings as keys
Enums are usually associated with an integer "value" and a String
description. The only value is that you might be able to get some
optimization by using the integer value of the enum in some cases. I
don't know that it is worth the effort to support it.
Unless enums have some other advantage that we did not think of. Takeshi can you
describe the advantages of enums that you see?
* How does a framework provide translated messages [1] to i8ln layer?
Can we also use the MDC here to push them in, and have the appender
read them?
I'm not sure I understand the question. The framework will provide a
method like:
public String getMessage(String key, Object[] params);
However the messages are stored is hidden behind the implementation of
that interface. Something has to call getMessage(). Potential places are
a) the application before calling SLF4J b) SLF4J before calling a
logging implementation, c) In the logging implementation - such as in
the Appender.
Bingo. a), b) or c) is the question. There is also a) and b) combined. See my
previous message.
Again, that depends. For example, Lillith
(http://freshmeat.net/projects/lilith-viewer) is an event viewer for
Logback. It would be very appropriate for it to do this. Likewise with
Apache Chainsaw for Log4j. Doing the L10N further up the chain limits
the flexibility these tools can provide. Sometimes that is desirable,
but my recommendation is to always start from as far back as possible
and move up the stack only as far as you have to.
If SLF4J or logback provided a reasonable solution, it would help developers in
solving the logging i18n issue by the mere fact of offering and thus blessing a
solution. It could only do harm if the offered solution was particularly stupid
or bad. Moreover, the solution provided in slf4j or logback (or in both in part)
could lay the foundation of a better solution imagined by one of our users.
Ralph
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev