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

[Joerg Hohwiller]

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

Hi Curt,

Curt Arnold wrote:
>> 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).
> 
> 
> I don't believe that it has anything particular to do with NLS or  i18n,
> just a desire to be able to bypass the cost of message  construction
> when logging is disabled without having to add a whole  lot of 
> logger.isDebugEnabled() cruft.
Okay.
> 
> 
>> 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.
>>
> 
> I agree that the number of methods and code duplication is 
> undesirable.  Maybe it would be better to isolate all the formatting 
> variants into a single concrete LogFormat class and have the Logger 
> interface only supply the most basic of the log methods that the  actual
> implementation would need to provide.  Something like:
> 
> //  direct use of org.slf4j.Logger
> logger.debug("Hello, world");
> 
> or
> 
> LogFormat.debug(logger, "Hello, {}.", location);
> 
> which could be implemented:
> 
> public static void debug(Logger logger, String format, Object param1) {
>     if (logger.isDebugEnabled()) {
>          logger.debug(MessageFormat.format(format, param1));
>     }
> }
> 
> I'd guess a JIT could effectively inline that code.
You exaclty clearified what I was trying to point out.
Nice approach.
> 
> 
>> 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.
> 
> 
> 
> I was assuming that SLF4J was using java.text.MessageFormat  internally,
> but a code review suggests that is not the case.   MessageFormat seems
> to have been around forever so it does not appear  to be an attempt to
> support some earlier JVM's.  I'd be interested to  know the motivation
Its not that old - anyways it does not hava an @since tag that makes it
clear. Thesedays SUN has dropped support for all JVMs older thant 1.4.2.
So do you care if it was not in 1.0 or 1.1?
Well if it was not in 1.3 that would be a point but I do not think so.
> for not using MessageFormat in SLF4j.  However,  it is my impression
> that the org.slf4j.MessageFormatter is trying to  mimic
> java.text.MessageFormat, at least on the pattern syntax.
> 
> Currently org.slf4j.Logger had a lot of special case signatures (0 
> parameter, 1 parameter, 2 parameter, etc) but did not have the  general
> case (the Object[] case).  The special cases are likely only  justified
> for the debug variants since info, warn and error messages  should be
> sufficiently rare that you could afford an array creation  on a call.
> 
MessageFormat is a standard so many people know its syntax. It is more
powerfull that just doing the replacement of a variable. BTW It also
solves some NLS issues.

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

iD8DBQFC8/FcmPuec2Dcv/8RAvGVAJ46Ia1ekFrbxOjZmcOs7y+E78u1swCffXTx
LEj2uIx9l/yfwOm05ZNKZwc=
=pa+c
-----END PGP SIGNATURE-----