- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 23 Jun '19

23 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-371: ----------------------------------- @ceki also, there is something wrong with the alpha release of source files.....all other 3rd party releases that gradle is downloading including the old slf4j version I used where bringing down the source so when I navigate into the 3rd party library, I am in the source code. For the new slf4j, eclipse is only opening *.class files and not the *.java files :(. This makes it harder to debug what is going on in the situations above to help out more :(. > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 23 Jun '19

23 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-371. ------------------------------ Resolution: Fixed See slf4j version 2.0.0-alpha0. The API is still evolving. Comments welcome. > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-371: ----------------------------------- @Federico sorry, it is a logback feature so you can't reproduce. it is an AWESOME feature when doing development. Webpieces uses this pattern <pattern>%date\{ISO8601} [%X\{txId}-%X\{user}] [%thread] %caller\{1..2} %-4level: %message%n</pattern> The %caller\{1..2} is very special and breaks down when using a wrapper like slf4j-fluent. That little bit inserts a 'clickable' link in the IDE's logging like so "at org.webpieces.plugins.hibernate.TransactionFilter.filter(TransactionFilter.java:47)" and it's sick while developing as I can click on ANY log statement and it takes me right to the log statement BUT only for people using the wrapper and we all know too many 3rd party jars are not using the wrapper so it only half works now :(. @ceki oh, crap!!! I didn't know that was out. I will have to try that out! thanks. > 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 > > > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Federico Fissore commented on SLF4J-371: ---------------------------------------- Sorry, I still don't get it. So I made some code [https://github.com/ffissore/test-sfl4j] If you ran App main method, you'll see 2 log statements that I made with and without using slf4j-fluent, plus a bunch of log statements triggered by apache common http client All statements are reporting the right lines in all files What am I missing? Can you show me with a PR or with code? > 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 > > > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-371: ---------------------------------- [~deanhiller] Have you tried SLF4J 2.0.0-alpha0 ? > 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 > > > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-371: ----------------------------------- @Federico ... I think perhaps I am not being clear. Sure slf4j-fluent just like our wrapper works fine 'by itself'. If every 3rd party library also uses slf4j-fluent(or any wrapper), there would also be know issue However, say you have a 3rd party library that you bring in that uses slf4j, and say your code uses the wrapper. The log statement by the 3rd party is 1 stack frame away while the wrapper is 2 stack frames away. This means, log statements that use your wrapper can work fine while the 3rd party log statements no longer work as it goes up the stack 2 times and finds the wrong frame/file/line location. I just went and tested this and sure enough...it does not work :(.(but I mean, it should be obvious since slf4j uses the stack frames to get this info) In webpieces development, it is my preference that I can click 'any' log statement and it will take me to my code or 3rd party code correctly. unfortunately, we have to back out of all wrappers including slf4j-fluent. later, 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 > > > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Federico Fissore commented on SLF4J-371: ---------------------------------------- AFAICT slf4j-fluent logs the right thing, despite being a wrapper itself, if the actual logger is a LocationAwareLogger. Take a look at https://github.com/ffissore/slf4j-fluent/blob/master/src/main/java/org/fiss… > 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 > > > 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)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 20 Jun '19

20 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-371: ----------------------------------- @Robert @Federico @Eric the issue with 'build your own' which I did is that the call stack in development mode 'breaks'. ie. in our development server, we have slf4j log EVERY location(clickable in the IDE) using a special feature. If you build your own, you must configure for caller + 2 BUT THEN the 3rd party libraries log the wrong location. ie. we built our own and found out all 3rd party libraries were broken so we need to revert it all so the feature of clicking a log goes right to the log statement in Intellij and in Eclipse!!! As an example, in Dev mode only as this has a 'performance cost' 2019-06-20 15:14:52,948 [-] [selectorThread] Caller+1 at org.webpieces.frontend2.impl.HttpServerImpl.lambda$0(HttpServerImpl.java:37) INFO: now listening for incoming requests on /0:0:0:0:0:0:0:0:8080 we can click on HttpServerImpl.java:37 in the IDE and end up right at the log statement, but since this is with our wrapper, the 3rd party log statements log the wrong location/wrong line number :(. This FEATURE ROCKS BTW. We use it on [https://github.com/deanhiller/webpieces] I need to go back and revert all of the slf4j wrapper though :(....not fun. 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 > > > 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)

1 0

JDK 13 enters Rampdown Phase One
by Rory O'Donnell 16 Jun '19

16 Jun '19

Hi Ceki, *JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/* * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. * Changes in this build 25 [4] *Request for feedback on JEP 353 integrated in b24 * JEP 353: Reimplement the Legacy Socket API" has been integrated into jdk-13+24. It would be very useful if applications or libraries using java.net.Socket or java.net.ServerSocket APIs could test with this build and report any issues found. The JEP provides information on the system property that can be used to switch back to the old implementation and that may be useful to check for behavior differences between the old and new implementation. It would be very useful to get feedback via the OpenJDK net-dev mailing list, bugs via the usual channel. *Updates to Release Notes since last email* * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 <https://bugs.openjdk.java.net/browse/JDK-8215032>) * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 <https://bugs.openjdk.java.net/browse/JDK-8222145>) * b24 - Reimplement the Legacy Socket API(JDK-8221481 <https://bugs.openjdk.java.net/browse/JDK-8221481>) o see above request for feedback * b24 - Deprecated rmic tool For Removal(JDK-8217412 <https://bugs.openjdk.java.net/browse/JDK-8217412>) * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 <https://bugs.openjdk.java.net/browse/JDK-8224767>) * b23 - Support for Unicode 12.1 (JDK-8221431 <https://bugs.openjdk.java.net/browse/JDK-8221431>) * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 <https://bugs.openjdk.java.net/browse/JDK-8221432>) *OpenJDK 14 **Early Access build 1 **is now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build [5] ** Rgds, Rory [1] http://openjdk.java.net/projects/jdk/13/#Schedule <http://openjdk.java.net/projects/jdk/12/#Schedule> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html [3] http://jdk.java.net/13/release-notes [4] JDK 13 - Changes in b25 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3…> [5] JDK 14 - Changes in b1 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A…> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0