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 > [email protected] > http://qos.ch/mailman/listinfo/slf4j-dev _______________________________________________ slf4j-dev mailing list [email protected] http://qos.ch/mailman/listinfo/slf4j-dev
