[slf4j-user] Internationalisation of log messages

simon skitching at apache.org
Sun Dec 16 11:28:05 CET 2007


Hi,

I have a number of questions about generating internationalised log
messages.

(1)

In the java.util.logging API, a resource-bundle name can be provided
when fetching a Logger instance:

 Logger log = Logger.getLogger("category", "logMsgBundle");
 log.log("key1", arg1, arg2, arg3);

As far as I can see, slf4j supports the second part of this (multiple
args), but not the first (specifying the resource bundle).

So with slf4j, how is the underlying log implementation supposed to find
the right resource bundle to create the final message to output?

I see here that writing a "filter" is suggested:
  http://www.nabble.com/Internationalization--to8698529.html

But that code would be (a) specific to a particular logging
implementation, and (b) have to be configured by the user in their
logging configuration, yes?

And if the logging lib is just in a parent classpath, while the app
doing the logging is in a child classpath, then aren't there problems
with the filters not having the resource bundle on the classpath?

Why doesn't slf4j take a resource-bundle as a parameter to the getLog
method? Is it because then:
  Logger log1 = LogFactory.getLogger("cat1", "res1");
  Logger log2 = LogFactory.getLogger("cat2", "res2");
would require supporting multiple Logger objects for a single category,
and this is tricky to implement efficiently?

(2)

It appears from the code that for slf-over-jcl and slf-over-log4j, if a
call like this is made:
   log.info("key1", arg1, arg2, arg3)
then all that is passed to the underlying logging impl is the key,  ie
   [INFO] key1
is what gets output.

This kind of think would work:
   log.info(
    "A problem in {0} occurred because {1} did {2}",
    arg1, arg2, arg3)
but leads to some rather odd "keys" in the message bundles.

Have I understood this right?


Does anyone else out there have experience with using SLF4J to generate
internationalised log messages?

Regards,

Simon




More information about the slf4j-user mailing list