[slf4j-dev] [JIRA] (SLF4J-124) Add ability to log at a dynamic level

[QOS.CH (JIRA)]

    [ 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)