[slf4j-dev] Release of SLF4J version 1.6.0-RC0

Ralph Goers rgoers at apache.org
Sat May 1 03:45:29 CEST 2010


On Apr 30, 2010, at 10:16 AM, Ceki Gülcü wrote:

> 
> 
> > If that's not the issue then please explain it to me.
> 
> I tried. See above. In a nutshell, I'd like to avoid painting
> ourselves to a corner. :-)
> 

I understand what you think is the issue. However, the unintended side effect that introducing LoggingEvent will have is this:

LoggingEvent event = new LoggingEvent(Level.DEBUG).add(marker);

event.setMessage(message1);
logger.log(event);
event.setMessage(message2);
logger.log(event);

For this to work the logging implementation has to make a new copy of the logging event. Otherwise, if an appender were to cache logging events, as they can safely do now (i.e. ListAppender), and then write them in batches events would get lost. Asynchronous appenders would also have to do this.

The only way I've thought of to make this useful is to do something like:

public class LogHeader {
 	private Level level;
	private Marker marker;

        public void addMarker(Marker marker) {
		this.marker = marker;
        }

        public log(Message msg) {
             logger.log(this, msg);
        }
}

public class Debug extends LogHeader {
        public Debug() {;
             setLevel(Level.DEBUG);
        }
}

public class Error extends LogHeader {
        public Error() {
             setLevel(Level.ERROR);
        }
}

private static final Debug DEBUG = new Debug();

logger.log(DEBUG, msg);

However, I don't think this does much to address what you think is a problem. 

Ralph









More information about the slf4j-dev mailing list