[slf4j-dev] slf4j i8ln

[ralph.goers @dslextreme.com]

On Thu, Aug 20, 2009 at 10:07 AM, Takeshi Kondo <takeshi.kondo at gmail.com>wrote:

>
> If log level is separated, logging code is
> ----
> public class enum LogMessages{
>   @Debug("debug log message")
>   TEST0001
> }
>
> if(logger.isEnableFor(LogMessages.TEST0001)){
>   logger.log(LogMessages.TEST0001);
> }
> ----
> If change log level, logger.isEnableFor(LogMessages.TEST0001) is true ,
> then  log event occur.


Actually, when using logger.log(LogMessages.TEST0001) isEnableFor is useless
and shouldn't be called. The log method is going to do that check again. But
your point is well taken that the application programmer doesn't have to
know the log level when writing the code.


>
> Of course, if we can change log configuration, it is usually solved. But
> because log configuration is per category,it can't configure per log message
> id.
>
>
>  Instead of debating the requirements, how about code that embodies your
>> vision of the API (assuming everything was possible)?
>>
>> For example, here is a vision of the i18n API:
>>
>>  LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
>>  lc.addResourceBundle( aResourceBundle);
>>
>>  Logger loggerA =  LoggerFactory.getLogger("A");
>>  Logger loggerB =  LoggerFactory.getLogger("B");
>>
>>  // replace key_0 with its corresponding value in aResourceBundle
>>  loggerA.info("key_0");
>>
>>  // same as before, but also insert the value of "param" as specified in
>>  // the message
>>  loggerB.info("key_1", param);
>>
>> The above is just an *example* of what I mean by "vision" of the API.
>>
>> You can go a step further an implement something. You may wish to fork
>> SLF4J on git. The url is http://github.com/ceki/slf4j/tree/master
>>
> OK. I've develop initial thought of  i18n API on this week end.
>
>
I'd love to see what you come up with. I'm seriously thinking that XLogger
could be enhanced with some of these ideas.

Ralph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20090820/60272eea/attachment.htm>