SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-371 ============================== 1 comment ------------------------------ Eric Kolotyluk on 27/Dec/21 4:05 PM Ahhh, now I see it...

From [https://www.slf4j.org/manual.html#fluent] I did not see the last example {code:java} // using fluent API, add one argument with a Supplier and then log message with one more argument. // Assume the method t16() returns 16. logger.atDebug().addArgument(() -> t16()).log(msg, "Temperature set to {}. Old temperature was {}.", oldT); {code} It is very subtle and could be 'marketed' better as lambda support. Wrapping my head around an unfamiliar API was very distracting when my mission was to just use lambdas.

I tested this in my code, and yes, it does work. However, I will stay with {code:java} import kr.pe.kwonnam.slf4jlambda.LambdaLogger; import kr.pe.kwonnam.slf4jlambda.LambdaLoggerFactory; . . . static final LambdaLogger logger = LambdaLoggerFactory.getLogger(LagTests.class); {code} As it does exactly what I want, and it keeps my code from looking too ugly with Fluent calling conventions. {code:java} Callable task = () -> {System.out.println("task evaluated"); return "called";}; logger1.debug("Lazy logging {}", task); logger2.atDebug().addArgument(task).log("Lazy logging {}"); {code} I really do not understand the objections to adding to slf4j what slf4jlambda does so well. It seems to me people are trying to advocate for Fluent rather than just a support a simple facade for logging that supports lambdas in a very natural way. Forcing people to use Fluent just to get lambdas is very manipulative. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)