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

[Ralph Goers]

In that case, SLF4J's LoggingEvent becomes even more pointless.  It adds more overhead/messiness to the caller to create these events purely for the sake of making SLF4J's api simpler. That is a very poor tradeoff IMO.

Ralph

On May 1, 2010, at 4:54 PM, Ceki Gülcü wrote:

> On 01/05/2010 3:45 AM, Ralph Goers wrote:
> > 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.
> 
> Logback's LoggingEvent is intended to be different than
> org.slf4j.spi.LoggingEvent. In all likelyhood, it (logback's
> LoggingEvent) will copy the data points from SLF4J's LoggingEvent so
> that the problem you mention will not arise.
> 
> --
> Ceki
> 
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev