[slf4j-dev] [JIRA] (SLF4J-371) Support the lambda expression in the Logger

[QOS.CH (JIRA)]

    [ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19662#comment-19662 ] 

Dean Hiller commented on SLF4J-371:
-----------------------------------

@Ceki so, uh, I am a bit confused as something seems off(maybe broken).  I am using the using the caller\{depth} feature found here [https://logback.qos.ch/manual/layouts.html]

Specifically, I have this pattern
{code:java}
<pattern>%date{ISO8601} [%X{txId}-%X{user}] [%thread] 2222 %caller{1} %-4level: %message%n</pattern>{code}
Notice the %caller\{1} piece.  I then have 'two' log statements like so
{code:java}
org.slf4j.Logger log2 = org.slf4j.LoggerFactory.getLogger(Server.class);

log2.atInfo().log(() -> "LOADING from meta file="+metaFile.getCanonicalPath());

log2.info("testing");{code}
 

The second one logs correctly and show the 'correct' file and correct line number like so
{code:java}
2019-06-23 13:08:17,003 [-] [main] 2222 Caller+0 at WEBPIECESxPACKAGE.DevelopmentServer.<init>(DevelopmentServer.java:67)

INFO: testing{code}
 

The other one 'should' be line 66 and DevelopmentServer.java as well but instead is such
{code:java}
2019-06-23 13:08:17,001 [-] [main] 2222 Caller+0 at org.slf4j.spi.DefaultLoggingEventBuilder.logViaPublicLoggerAPI(DefaultLoggingEventBuilder.java:120)

INFO: LOADING from meta file=/Library/Workflow/webpieces/webserver/webpiecesServerBuilder/templateProject/WEBPIECESxAPPNAME/src/main/resources/appmetadev.txt{code}
My 'personal' opinion is these new lazy loggers with regard to caller variable should 'shift' the stack trace so that caller depth matches in both cases.  A caller depth of 1 should be where I call slf4j, not deep in slf4j stack, right?

Notice that we do this in DEVELOPMENT mode only so developers can literally click on all logging statements and it takes them right to the code that logged it.

thanks,

Dean

> Support the lambda expression in the Logger
> -------------------------------------------
>
>                 Key: SLF4J-371
>                 URL: https://jira.qos.ch/browse/SLF4J-371
>             Project: SLF4J
>          Issue Type: Improvement
>          Components: Core API
>    Affects Versions: 1.7.22
>            Reporter: MiNG
>            Assignee: SLF4J developers list
>             Fix For: 2.0.0-alpha1
>
>
> In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following:
> {code:java}
> if (LOGGER.isWarnEnabled())
> {
>  LOGGER.warn("some message: {}", Json.serialize(obj));
> }{code}
> Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly.
> Now, the lambda expression is supported by JDK8, the above could be simplified like following:
> {code:java}
> LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code}
> With the default method definition in the org.slf4j.Logger:
> {code:java}
> public interface Logger
> {
>  default void warn(Function<MessageFormatter, String> messageSupplier)
>  {
>   if (this.isWarnEnabled())
>   {
>    /* Calculate the expression only if the WARN level logging is enabled. */
>    this.warn(messageSupplier.apply(this.getFormatter()));
>   }
>  }
> }{code}



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)