[slf4j-dev] slf4j i8ln

[Takeshi Kondo]

>
> Takeshi mentioned that his requirement was to be able to change the  
> level of a logging statement without needing to recompile his  
> application. I don't see how annotations help in this case since  
> they also need to be recompiled.
>
I think annotation is default value.
  In development, I don't want to write property file because property  
file isn't type safe. so I want to use annotation.
  In contrast, after deployment I don't want to recompile our  
application because redeployment process is onerous task. so I want to  
use property file.

Who should develop log level?
I think application developer develop default log level, and operator  
develop actual log level.
I can't design all log level if it doesn't operate it.

> Markers allow for a cleaner way of filtering out messages. Changing  
> the level is unnecessary. For example, if all logging events of  
> level ERROR trigger an alarm, and if a certain ERROR event should  
> not trigger an alarm, you can mark that particular event with the  
> "NO_ALARM" marker.
All right, I think so.
In this use case ,If I can mark that particular ERROR event with the  
"NO_ALARM" marker without recompile. I don't need it.

In other use case, I usually change particular log level from debug to  
info to analyze trouble after deployment. In this use case, I think  
Markers don't resolve it. Because debug logging code is

if( logger.isDebugEnabled()){
    logger.debug("debug log message ....");
}

logger.isDebugEnabled() is false, then  debug log even don't occur.
----

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.
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.

Takeshi Kondo