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
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
