[slf4j-dev] event API in SLF4J

[Ralph Goers]

Ceki,

SLF4J has methods that take discrete parameters so that it can avoid constructing the LoggingEvent if it does’t need to. This kind of turns that upside down.  That said, Lambdas create an object that contains the expensive logic to execute, without executing that logic until necessary. Typically the cost of creating the Lambda objects is insignificant.  Log4j 2 already supports Lambdas while still only requiring Java 7 - we just use our own Supplier interface. 

I am not sure I see how what you are proposing here correlates at all to what using lambda expressions achieves. In your proposal the user has to construct the LoggingEvent before calling the log method, which implies that the whole thing needs to be wrapped in an if (logger.isDebugEnabled()) block. Lambdas free you from that.

OTOH, it was proposed to you years ago that SLF4J accept Messages [1] - as Log4j 2 does now. I believe this yields more gains than what one would get with your proposal. I think exposing a LoggingEvent that includes the Marker and Level is a bad idea. While the Message interface allows for users to log complex objects, it does so by only solving for that problem and does not introduce fields that really have nothing to do with the message content being delivered.

Although a bit off topic, I should point out that if SLF4J provided an AbstractLogger class that the impact of adding new methods to the Logger interface would pretty much be a non-issue. Most of the time the class extending AbstractLogger wouldn’t need to change. Currently the Log4j 2 API has 192 methods. If AbstractLogger is extended only 7 methods need to be implemented. 

Ralph

[1] http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html <http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20160125/20b7baaa/attachment.html>