- slf4j-dev - mailman3.qos.ch

JDK 12 , JDK 8u202 & Project Panama Early-Access builds available
by Rory O'Donnell 09 Nov '18

09 Nov '18

Hi Ceki, *JDK 12 Early Access build 19 is available at : - jdk.java.net/12/* * 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>. * Release Notes updates since last email o Build 18 – JDK-8211883: Disable anon and NULL cipher suites + Crypto Roadmap <https://java.com/en/jre-jdk-cryptoroadmap.html> Updated o Build 17 – JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume o Build 16 – JDK-8211866: TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms o Build 17 – JDK-8195793 : Remove GTE CyberTrust Global Root o Build 16 - JDK-8191053 : Provide a mechanism to make system's security manager immutable * JEPs proposed for JDK 12 so far: o JEP 230 - Microbenchmark Suite <https://openjdk.java.net/jeps/230> * JEPs targeted to JDK 12, so far o 325: Switch Expressions (Preview) <http://openjdk.java.net/jeps/325> o 326: Raw String Literals (Preview) <http://openjdk.java.net/jeps/326> o 340: One AArch64 Port, Not Two <http://openjdk.java.net/jeps/340> o 341: Default CDS Archives <http://openjdk.java.net/jeps/341> *JDK 8u202 Early Access build 03 is available at : - **http://jdk.java.net/8/* * JDK 8u202 timeline is available [1] o GA is scheduled for January 2019 *Project Panama Early-Access build 0 ***is available at : - http://jdk.java.net/panama/ ** * Early access builds from Project Panama <https://openjdk.java.net/projects/panama/> * 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>. * Feedback - Please send feedback via e-mail to panama-dev(a)openjdk.java.net <mailto:panama-dev@openjdk.java.net>. * To send e-mail to this address you must first subscribe to the mailing list <http://mail.openjdk.java.net/mailman/listinfo/panama-dev>. *Crypto Roadmap Updated [2] * Rgds,Rory [1] http://openjdk.java.net/projects/jdk8u/releases/8u202.html [2] https://java.com/en/jre-jdk-cryptoroadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 09 Nov '18

09 Nov '18

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Jörg Sesterhenn commented on SLF4J-437: --------------------------------------- For an example see: [https://github.com/eonian-technologies/slf4j-bom/blob/master/pom.xml] I would rather use a bom provided by the project itself, than a bom by someone else. There is another example in https://jira.qos.ch/browse/SLF4J-365 Please reconsider. Many widely used Frameworks (with more than one module) provide a BOM (log4j, spring, arquillian, weld, deltaspike,...). It is important to us and will ease dependency management. > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-447) Slf4j-ext contains package org.slf4j
by QOS.CH (JIRA) 02 Nov '18

02 Nov '18

Pavel_K created SLF4J-447: ----------------------------- Summary: Slf4j-ext contains package org.slf4j Key: SLF4J-447 URL: https://jira.qos.ch/browse/SLF4J-447 Project: SLF4J Issue Type: Bug Components: slf4j-ext Affects Versions: 1.8.0-beta2 Reporter: Pavel_K Assignee: SLF4J developers list Slf4j-ext includes package org.slf4j (class org.slf4j.NDC) what is a serious problem if we use slf4j with JPMS. For example, we can't build log4j-slf4j18-impl for JPMS because it uses both slf4j-api and slf4j-ext and both these modules export the same package - org.slf4j. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 16 Oct '18

16 Oct '18

[ https://jira.qos.ch/browse/SLF4J-420?page=com.atlassian.jira.plugin.system.… ] Varun Nandi commented on SLF4J-420: ----------------------------------- Any updates? We are blocked by this issue. Please let us know how we can help. > Make a release with Automatic-Module-Name > ----------------------------------------- > > Key: SLF4J-420 > URL: https://jira.qos.ch/browse/SLF4J-420 > Project: SLF4J > Issue Type: Task > Reporter: Gael Lalire > Assignee: Ceki Gülcü > Priority: Trivial > Fix For: 1.7.26 > > > You can make a release with Automatic-Module-Name with 1.7 version so it can load logback and have the package name you choose in 1.8 beta. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 12 Early Access build 15 is available
by Rory O'Donnell 15 Oct '18

15 Oct '18

Hi Ceki, *JDK 12 Early Access build 15 is available at : - jdk.java.net/12/* * JDK 12 Schedule is confirmed. o 2018/12/13 Rampdown Phase One <http://openjdk.java.net/jeps/3#rdp-1> o 2019/01/17 Rampdown Phase Two <http://openjdk.java.net/jeps/3#rdp-2> o 2019/02/07 Release-Candidate Phase <http://openjdk.java.net/jeps/3#rc> o 2019/03/19 General Availability * Release Notes for JDK 12 [1] * JEPs targeted to JDK 12, so far o 325: Switch Expressions (Preview [2]) - Integrated o 326: Raw String Literals (Preview [2]) - Integrated o 340: One AArch64 Port, Not Two <http://openjdk.java.net/jeps/340> - Targeted o 341: Default CDS Archives <http://openjdk.java.net/jeps/341>- Integrated * Important fixes since last email o (b15) Implementation of JEP 341: Default CDS Archives o (b14) LDAPS Communication Failure (JDK-8211107 <https://bugs.openjdk.java.net/browse/JDK-8211107>) o (b14) Support dns_canonicalize_hostname in krb5.conf (JDK-8210821 <https://bugs.openjdk.java.net/browse/JDK-8210821>) o (b14) Removal of com.sun.awt.SecurityWarning Class (JDK-8210692 <https://bugs.openjdk.java.net/browse/JDK-8210692>) *JDK 8u202 planning [3]* * 8u202 is proposed to be the last Oracle led release for this OpenJDK Project. * A proposed timeline is as follows : o July 2018 8u-dev forest begins collecting 8u202 fixes o Mid October 2018 RampDown 2 o Mid January 2019 GA Rgds, Rory [1] http://jdk.java.net/12/release-notes [2] http://openjdk.java.net/jeps/12 [3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html<http://jdk.java.net/12/release-notes> <https://download.java.net/java/early_access/jmc7/core/common/docs/api/overv…> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-446) Update JavaDoc on Logger to explicitly state desired functionality.
by QOS.CH (JIRA) 04 Oct '18

04 Oct '18

Andrew Glassman created SLF4J-446: ------------------------------------- Summary: Update JavaDoc on Logger to explicitly state desired functionality. Key: SLF4J-446 URL: https://jira.qos.ch/browse/SLF4J-446 Project: SLF4J Issue Type: Improvement Components: Core API Reporter: Andrew Glassman Assignee: SLF4J developers list Priority: Minor {{In slf4j-api/src/main/java/org/slf4j/Logger.java i}}t is not specified in the JavaDoc that the last parameter of string templated arrays are expected to be treated differently if they extend Throwable. Pull request that addresses this issue: https://github.com/qos-ch/slf4j/pull/185 JavaDoc on the interface should explicitly state that if the last element of the array extends Throwable, it will not be used to template the string, and will be "the exception (throwable) to log". Documenting this expected functionality in docs outside of the JavaDoc is fine, but it should explicitly be stated in the interface contract if implementations are expected to do that. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release Announcement: General Availability of JDK 11
by Rory O'Donnell 26 Sep '18

26 Sep '18

Hi Ceki, *1) Release Announcement: General Availability of JDK 11 * * JDK 11, the reference implementation of Java 11 and the first long-term support release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/11 This release includes seventeen features: * 181: Nest-Based Access Control <http://openjdk.java.net/jeps/181> * 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309> * 315: Improve Aarch64 Intrinsics <http://openjdk.java.net/jeps/315> * 318: Epsilon: A No-Op Garbage Collector <http://openjdk.java.net/jeps/318> * 320: Remove the Java EE and CORBA Modules <http://openjdk.java.net/jeps/320> * 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321> * 323: Local-Variable Syntax for Lambda Parameters <http://openjdk.java.net/jeps/323> * 324: Key Agreement with Curve25519 and Curve448 <http://openjdk.java.net/jeps/324> * 327: Unicode 10 <http://openjdk.java.net/jeps/327> * 328: Flight Recorder <http://openjdk.java.net/jeps/328> * 329: ChaCha20 and Poly1305 Cryptographic Algorithms <http://openjdk.java.net/jeps/329> * 330: Launch Single-File Source-Code Programs <http://openjdk.java.net/jeps/330> * 331: Low-Overhead Heap Profiling <http://openjdk.java.net/jeps/331> * 332: Transport Layer Security (TLS) 1.3 <http://openjdk.java.net/jeps/332> * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) <http://openjdk.java.net/jeps/333> * 335: Deprecate the Nashorn JavaScript Engine <http://openjdk.java.net/jeps/335> * 336: Deprecate the Pack200 Tools and API <http://openjdk.java.net/jeps/336> 2) Quality Outreach Report for September 2018 is available* * * Quality Outreach report September 2018 *Thanks to everyone who contributed to JDK 11 by downloading and testing the early-access builds. In particular the following developers who logged **18 issues in the JDK Bug System.* * Netty * Eclipse Jetty * Apache Lucene * JUnit5 * Apache Tomcat * Apache Ant * Apache POI * AssertJ * Eclipse Collections * Byte Buddy * RxJava 3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are now available at http://jdk.java.net/11 . * Schedule , Status & Features o http://openjdk.java.net/projects/jdk/12/ * Release Notes: o http://jdk.java.net/12/release-notes ** Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

[JIRA] (SLF4J-445) Skip SubstituteLogger from caller data (slf4j-jdk14)
by QOS.CH (JIRA) 25 Sep '18

25 Sep '18

Alexander Yevsyukov created SLF4J-445: ----------------------------------------- Summary: Skip SubstituteLogger from caller data (slf4j-jdk14) Key: SLF4J-445 URL: https://jira.qos.ch/browse/SLF4J-445 Project: SLF4J Issue Type: Bug Components: Implementations Affects Versions: 1.7.25 Environment: Slf4j-jdk14 binding Reporter: Alexander Yevsyukov Assignee: SLF4J developers list When using \{\{SubstituteLogger}} with \{\{JDK14LoggerAdapter}} (obtained regularly via \{\{LoggerFactory}}) the output always gives \{\{SubstituteLogger}} as the caller. A programmer would be interested in the class/method of his code. The issue is that \{\{JDK14LoggerAdapter.fillCallerData()}} does not take into account that \{\{SubstituteLogger}} can be the direct caller, and it is needed to go one level deeper. This issue is similar to [one reported to LogBack|https://jira.qos.ch/browse/LOGBACK-1100]. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 13 Sep '18

13 Sep '18

[ https://jira.qos.ch/browse/SLF4J-420?page=com.atlassian.jira.plugin.system.… ] Varun Nandi commented on SLF4J-420: ----------------------------------- Hi, Any updates? Can you atleast let us know when you are planning to GA a version that is compatible with Java 9 module system. Our GA is blocked by this issue. If we depend on 1.7.26, the module name is derived from the jar. Then if you change the module name in 1.8, all our customers will be broken. I see following 2 options: 1) Release a GA version of 1.8.x with Java module info 2) Release a patch version on top of 1.7.26 with "Automatic-Module-Name" in the manifest See this article for better understanding of the issue: [https://dzone.com/articles/automatic-module-name-calling-all-java-library-m…] Thank you > Make a release with Automatic-Module-Name > ----------------------------------------- > > Key: SLF4J-420 > URL: https://jira.qos.ch/browse/SLF4J-420 > Project: SLF4J > Issue Type: Task > Reporter: Gael Lalire > Assignee: Ceki Gülcü > Priority: Trivial > Fix For: 1.7.26 > > > You can make a release with Automatic-Module-Name with 1.7 version so it can load logback and have the package name you choose in 1.8 beta. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-444) Allow explicitly selecting a binding
by QOS.CH (JIRA) 07 Sep '18

07 Sep '18

Christopher Smith created SLF4J-444: --------------------------------------- Summary: Allow explicitly selecting a binding Key: SLF4J-444 URL: https://jira.qos.ch/browse/SLF4J-444 Project: SLF4J Issue Type: Improvement Affects Versions: 1.7.25 Reporter: Christopher Smith Assignee: SLF4J developers list The binding autoconfiguration in SLF4J is very handy, but it comes with a severe limitation in testing: Neither Eclipse nor IntelliJ can handle a test-scope exclude (e.g., Surefire's {{classpathDependencyExclude}}), and so for an end project (such as a Spring Boot application), it's impossible to run tests that use slf4j-test in the IDE. It would be very helpful for testing purposes if there were a way to specify (probably in a {{META-INF}} file) the preferred logger to use in the case of finding multiple bindings on the classpath. Then dropping an instruction in {{src/test/resources}} would allow tests to run with the test logger without tangling classpath issues into the run. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0