[
https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050#comment-18050
]
Anders Kreinøe commented on SLF4J-124:
--------------------------------------
Now where slf4j actually has an Level enum, what about adding a log(Logger
logger, String msg) method to the enum, instead of a generic log(Level level,
String msg) method to Logger. It could look something like this:
{code:java}
public enum Level {
ERROR(ERROR_INT, "ERROR") {
@Override
public void log(Logger logger, String msg) {
logger.error(msg);
}
},
WARN(WARN_INT, "WARN") {
@Override
public void log(Logger logger, String msg) {
logger.warn(msg);
}
},
INFO(INFO_INT, "INFO") {
@Override
public void log(Logger logger, String msg) {
logger.info(msg);
}
},
DEBUG(DEBUG_INT, "DEBUG") {
@Override
public void log(Logger logger, String msg) {
logger.debug(msg);
}
},
TRACE(TRACE_INT, "TRACE") {
@Override
public void log(Logger logger, String msg) {
logger.trace(msg);
}
};
private int levelInt;
private String levelStr;
Level(int i, String s) {
levelInt = i;
levelStr = s;
}
public int toInt() {
return levelInt;
}
/**
* Returns the string representation of this Level.
*/
public String toString() {
return levelStr;
}
public abstract void log(Logger logger, String msg);
}
{code}
Then you can define a method taking a Level instance, and just call log on
that. No need to know what level it actually is:
{code:java}
public static void doSomethind(Level logAtLevel) {
// perform some logic
logAtLevel.log(loggerToLogTo, "The caller of this method has
decided " +
"what level this is logged at.");
}
{code}
This is only an example, a lot more methods would have to be difined on the
level class, to support markers, and arguments for {} replacements.
I see the following advantages when doing it this way:
# Adding a new method to Logger interface would breack the backward
compability, as it would force all implementations to implement these methods.
However adding a log method to level, is fully backward compatibly.
# I think this would give a cleaner implementation, without the need for
matching (either in a switch or with if/else statements) on the level in the
log methods.
# More typesafe. There will be no switch or if statements matching on the
level, to decide what method to call on the Logger instance. Thus adding an new
Level, will result in a compile error, until the needed log methods has been
implemented in that Level instance.
# It still possibly to add generic log.(Level level ...) methods in the Logger
interface if wanted (would still break backward compatibility), and the
implementation for these would be pretty easy, just call the corresponding
method on the supplied Level instance. It would be possibly to create an
abstract class implementing Logger, that provide the implementation for these,
that could be used by Logger implementations that do not need to extend an
other class.
I would be willing to work on this, and provide patches, but I will like to
know if its something that would surely be rejected, before doing any work.
> Add ability to log at a dynamic level
> -------------------------------------
>
> Key: SLF4J-124
> URL: https://jira.qos.ch/browse/SLF4J-124
> Project: SLF4J
> Issue Type: Improvement
> Components: Core API
> Affects Versions: 1.5.x
> Environment: Operating System: All
> Platform: All
> URL:
> http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-runtime-in-slf4j
> Reporter: Robert Elliot
> Assignee: SLF4J developers list
> Attachments: Util.java.patch
>
>
> It is occasionally useful to have a log method that takes a level as a
> parameter. The necessary methods can be added to the Util class without any
> compatibility issues as far as I can see - see attached patch.
--
This message was sent by Atlassian JIRA
(v6.4.12#64027)
_______________________________________________
slf4j-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
