- slf4j-dev - mailman3.qos.ch

[qos-ch/slf4j] fde8ca: refactor EventBuilder construction
by Ceki Gulcu 28 Jul '19

28 Jul '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: fde8ca480c86bd01dcca4d492e0fc5db56eb2619 https://github.com/qos-ch/slf4j/commit/fde8ca480c86bd01dcca4d492e0fc5db56eb… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-07-28 (Sun, 28 Jul 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/Logger.java M slf4j-site/src/site/pages/manual.html Log Message: ----------- refactor EventBuilder construction

1 0

[qos-ch/slf4j] 83b88c: fix JavaDoc typo
by Ceki Gulcu 26 Jul '19

26 Jul '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 83b88c502a322742f855bbb6e9d2f856dbd0d02d https://github.com/qos-ch/slf4j/commit/83b88c502a322742f855bbb6e9d2f856dbd0… Author: Artsiom Chapialiou <achapialiou(a)gmail.com> Date: 2019-07-25 (Thu, 25 Jul 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/ILoggerFactory.java Log Message: ----------- fix JavaDoc typo Commit: 7533fde7657e9577cd30bcf82584fb37207a99d4 https://github.com/qos-ch/slf4j/commit/7533fde7657e9577cd30bcf82584fb37207a… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-07-26 (Fri, 26 Jul 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/ILoggerFactory.java Log Message: ----------- Merge pull request #210 from ArtsiomCh/patch-1 fix JavaDoc typo Compare: https://github.com/qos-ch/slf4j/compare/a5357c8d49aa...7533fde7657e

1 0

JDK 13 enters Rampdown Phase Two
by Rory O'Donnell 22 Jul '19

22 Jul '19

Hi Ceki, Any issues to report on JDK 13 , would like to hear the status as we are now in rampdown phase 2 ? **OpenJDK builds *- JDK 13 Early Access build 30 **is now available **at : - jdk.java.net/13/* * Per the JDK 13 schedule [1], we are now in Rampdown Phase Two. 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. o Per the JDK Release Process [3] we now turn our focus to P1 and P2 bugs. * I want to draw your attention to some noteable changes in previous builds of JDK 13. These changes are important for those that develop/maintain their own socket implementation (java.net.SocketImpl) or use the setSocketImplFactory or setSocketFactory APIs to change the system-wide socket implementation: o http://jdk.java.net/13/release-notes#JDK-8224477 - delivered in build 23 o http://jdk.java.net/13/release-notes#JDK-8216978 - delivered in build 20 o http://jdk.java.net/13/release-notes#JDK-8220493 - delivered in build 13 **OpenJDK builds *- JDK 14 Early Access build 6 is **now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes of interest since last email o 8225239: Refactor NetworkInterface lookups o 8226409: Enable argument profiling for sun.misc.Unsafe.put*/get* * JEP targeted to JDK 14: o JEP352: Non-Volatile Mapped * Bug fixes reported by Open Source Projects : o JDK-8227080 - fixed in b5 -reported by Eclipse Jetty The Java Crypto Roadmap <https://www.java.com/en/jre-jdk-cryptoroadmap.html> has been updated : * Released - 16-July-2019 - Release Affected JDK 7u231 - Disabled Kerberos DES encryption by default * Targeted Date - 2020 - Targeted Release - JDK 8 - Transport Layer Security (TLS) 1.3 Rgds,Rory [1] http://openjdk.java.net/projects/jdk/13/#Schedule [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

JDK 13 , JDK 14 & Valhalla Early Access builds are available.
by Rory O'Donnell 08 Jul '19

08 Jul '19

Hi Ceki, **OpenJDK* 13 Early Access build **28 is now available **at : - jdk.java.net/13/* * 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 28 [1] *Reminder of a change in b24 - A jrt URI can only encode paths to files in /modules tree **(JDK-8224946 <https://bugs.openjdk.java.net/browse/JDK-8224946>)* A |jrt| URL is a hierarchical URI with syntax |jrt:/[$MODULE[/$PATH]]|. When using the |jrt| file system, a |java.net.URI| object can be created with the |java.nio.file.Path::toUri| method to encode a normalized path to a file in the |/modules| tree. A |jrt| URL cannot encode a path to a file in the |/packages| tree. The |jrt| file system provider has changed in this release so that |toUri| fails with |IOError| when it is not possible to encode the file path as a jrt URI. *This change may impact tools have been making use of URLs that are not compliant with the syntax. Tools with paths to files in **|/packages|**can use the **|toRealPath()|**method to obtain the real path (in **|/modules|**) before attempting to convert the file path to a URI.* *OpenJDK 14 **Early Access build 4 **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 [2] *Project Valhalla "L-World Inline Types" Early-Access Builds* * Build jdk-14-valhalla+1-8 * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Please send feedback via e-mail to valhalla-dev(a)openjdk.java.net <mailto:valhalla-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list. *The Skara tooling is now open source *[3] we are happy to announce that the tooling for project Skara is now open source and available at * https://github.com/openjdk/skara <https://github.com/openjdk/skara.> The Skara tooling includes both server-side tools (so called "bots") as well as several command-line tools ** If you have any questions, feedback etc. send them to Skara mailing list [4] Rgds, Rory [1] JDK 13 - Changes in b28 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B27%22%3A%3…> [2] JDK 14 - Changes in b4 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B3%22%3A%3A…> [3] https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/000047.html [4] https://mail.openjdk.java.net/mailman/listinfo/skara-dev -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (SLF4J-462) %caller broken with lamdas, etc. other in slfj4 2
by QOS.CH (JIRA) 01 Jul '19

01 Jul '19

[ https://jira.qos.ch/browse/SLF4J-462?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-462: ----------------------------------- oops on opening this. opened https://jira.qos.ch/browse/LOGBACK-1473 which is the correct project. > %caller broken with lamdas, etc. other in slfj4 2 > ------------------------------------------------- > > Key: SLF4J-462 > URL: https://jira.qos.ch/browse/SLF4J-462 > Project: SLF4J > Issue Type: Bug > Affects Versions: 2.0.0-alpha0, 2.0.0-alpha1 > Reporter: Dean Hiller > Assignee: SLF4J developers list > > oh, oops, this is a logback bug...need to file it there. ah crap, how to close this issue. I will open on logback. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-462) %{caller}
by QOS.CH (JIRA) 01 Jul '19

01 Jul '19

[ https://jira.qos.ch/browse/SLF4J-462?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-462: ----------------------------------- sorry, hit enter on accident....filling in right now. > %{caller} > --------- > > Key: SLF4J-462 > URL: https://jira.qos.ch/browse/SLF4J-462 > Project: SLF4J > Issue Type: Bug > Reporter: Dean Hiller > Assignee: SLF4J developers list > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-462) %{caller}
by QOS.CH (JIRA) 01 Jul '19

01 Jul '19

Dean Hiller created SLF4J-462: --------------------------------- Summary: %{caller} Key: SLF4J-462 URL: https://jira.qos.ch/browse/SLF4J-462 Project: SLF4J Issue Type: Bug Reporter: Dean Hiller Assignee: SLF4J developers list -- 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) 27 Jun '19

27 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-371: ----------------------------------- @ceki any comments? 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) 25 Jun '19

25 Jun '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Dean Hiller commented on SLF4J-371: ----------------------------------- @ceki should I create a ticket or? and what about GEventEvaluator? Seems it's not there anymore and it was helping to make our logs clean by putting warn/error in RED. 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) 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 hmmm, not sure on the source thing actually yet....something weird as I just tested out a new release of webpieces and intellij brought in the source so navigation worked while eclipse did not...that issue may be some new eclipse issue actually so my bad .....not clear yet tbh. I should have tested in intellij first. > 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