NLS in Logger (Re: [slf4j-dev] Logger.debug(String, Object[])?)

Joerg Hohwiller joerg at j-hohwiller.de
Fri Aug 5 23:02:39 CEST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everybody,

Curt Arnold wrote:
> Been reading the varargs stuff in JDK 1.5 and it seems like it might  be
> desirable to add methods that take an Object[] parameter in  addition to
> the existing Logger.debug(String, Object) methods.  For  example:
> 
> interface Logger {
> void debug(String format, Object param1); //existing method
> void debug(String format, Object[] params);
> }
> 
> The second form would be like a
> 
> void debug(String format, Object... params)
> 
> Obviously there would be a construction cost in constructing the  array
> unless you happened to happened to have it around.  However, if  you
> were willing to take the hit, it would open up all sorts of 
> combinations of parameters.
> 
> The implementation  would be something like:
> 
> void debug(String format, Object param1) {
>    if (isDebugEnabled()) {
>        String msg = MessageFormat.format(new Object[] { param1 });
>        logger.finer(msg);
>    }
> }
> 
> void debug(String format, Object[] params) {
>    if (isDebugEnabled()) {
>        String msg = MessageFormat.format(params);
>        logger.finer(msg);
>    }
> }
> 
> This way, you could do:
> 
> logger.debug("This first five letters of the latin alphabet are {},  {},
> {}, {}, {}.", new Object[] {"A", "B", "C", "D", "E" });

I actually got on the list with a very specific issue and my focus lies
on commons-logging, but anyways I want to point something out.
You might find it strage that I, who proposed the need for additional
methods in the Logger API, am saying this but:
In my opinion a logger API should be very simple and focus on logging.
What you are doing here is mixing logging with native language support
(NLS, i18n or however you call it). In my oppinion this is misplaced in
a Logging API (I mean all the formatting methods). A logger should take
an Object and if the according loglevel is enabled it should log
Object.toString() (checking for NULL of cause and these things).
The Object can be an NlsMessage that contains the internationalized
message with parameter objects to fill in.
Did you ever implement NLS in a multi-user server application?
The static way to access a default Locale is all you get from the JDK to
get the right ResourceBundle picked.
So the NlsMessage could use a translation service in its toString()
method where a ThreadLocal is used to get the context of the according
user and get the desired Locale.
You do not want to have logic like this inside a logger, right?
This is all about "separation of concerns".
But again you see I am one of these IoC container guyz and care very
much seperation of components and decoupled logic - maybe too much :)
Other people just want to have things done quickly and without using and
understanding frameworks or stuff like this and they might like to type
it like suggested above.
Anyways if you make it this way: the syntax with "{}" for me looks like
you are NOT using java.text.MessageFormat. Why is that? You do not need
to reinvent the wheel here. But maybe I am missing something.

Regards
  Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC89PvmPuec2Dcv/8RAvpFAJ9YuuEBlEVxo/i1ODMV60u7hlBFVQCdEFst
ZbvYyKht/jlv2a0kXf5vu0U=
=kkRU
-----END PGP SIGNATURE-----



More information about the slf4j-dev mailing list