- logback-dev - mailman3.qos.ch

JDK 16 is in Rampdown Phase One
by Rory O'Donnell 13 Dec '20

13 Dec '20

Hi Ceki, *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] . * *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule for JDK 16 o *2020/12/10 Rampdown Phase One* o 2021/01/14 Rampdown Phase Two o 2021/02/04 Initial Release Candidate o 2021/02/18 Final Release Candidate o 2021/03/16 General Availability * Release Notes [2] OpenJDK 16 Early Access build 28**is now available at http://jdk.java.net/16 * Features - the overall feature set is frozen. No further JEPs will be targeted to this release. * Significant Integrations in b28: o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by Default <https://openjdk.java.net/jeps/396>** * + Strongly encapsulate all internal elements of the JDK by default, except for critical internal APIs <https://openjdk.java.net/jeps/260#Description> such as |sun.misc.Unsafe|. + Allow end users to choose the relaxed strong encapsulation that has been the default since JDK 9. o Integrated JEP 397: Sealed Classes (Second Preview) <https://openjdk.java.net/jeps/397> with this release. + Enhance the Java programming language with sealed classes and interfaces <https://cr.openjdk.java.net/~briangoetz/amber/datum.html>. + Refines JEP 360 <https://openjdk.java.net/jeps/360> which was delivered in JDK 15 as a preview feature. * 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 recent builds that maybe of interest: o Build 28 + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by Default + JDK-8166596: TLS support for the EdDSA signature algorithm + JDK-8256718: Old tracing flags are now obsolete and must be replaced with unified logging o Build 27 + JDK-8159746: (proxy) Support for default methods + JDK-8254631: Better support ALPN byte wire values in SunJSSE Project Loom Early-Access: *Build 16-loom+9-316 <http://jdk.java.net/loom/>* (2020/11/30) - based on JDK-16+25 <https://github.com/openjdk/jdk/releases/tag/jdk-16%2B25> * 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> * These builds are intended for developers looking to "kick the tyres" and provide feedback on using the API or by sending bug reports. * Please send feedback via e-mail to loom-dev(a)openjdk.java.net <mailto:loom-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/loom-dev>. Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-December/004991.html [2] https://jdk.java.net/16/release-notes

1 0

[JIRA] Updates for LOGBACK-1544: Problem with program execution with log level WARN an OSGi
by QOS.CH (JIRA) 11 Dec '20

11 Dec '20

logback / LOGBACK-1544 [Open] Problem with program execution with log level WARN an OSGi ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1544 ============================== Issue created ------------------------------ Oliver Plohmann created this issue on 11/Dec/20 2:34 PM Summary: Problem with program execution with log level WARN an OSGi Issue Type: Bug Affects Versions: 1.2.3 Assignee: Logback dev list Attachments: logback.xml Components: logback-classic, logback-core Created: 11/Dec/20 2:34 PM Environment: We have a problem with several log statements not showing up in the log during startup of our application when logback is in log level WARN. Problem does not show up for INFO and DEBUG. Problem has showed up recently and disappears when changing <configuration scan="true"> to <configuration>. Interestingly, our logback.xml was defining <configuration scan="true"> all the time (for more than a year) without this problem, also in production. We are using the Felix OSGi container. For the missing log statements not written to the log when in log level WARN there is no problem that the code that issues those log statements were not executed. The whole startup process seems to run correctly without leaving out any startup steps as tons of things that need to be initialized for the application to work at all are carried out correctly. This can be seen from the application working correctly. However, when <configuration scan="true"> is defined rather than <configuration> the application startup fails. The code issuing log entries with level WARN seem not to be executed as the application is not correctly initialized after startup. Log statements in level INFO do not show up in the log. We can trace down the problem to a specific commit in git that first shows this problem. The difference in the code to the commit before, that is working without this problem, shows nothing meaningful. The code changes are all simple and are also not related to logging. Also no changes in setup like different JVM version or anything else like changes in the pom.xml. All changes are on Java code level. Removing the differences and creating another build results in an application jar that still shows the problem. This is a bit weird but confirmed by several pairs of eyes ;). We use the @Slf4j annotation from lombok and do so from the beginning without ever having had the issue described here. The issue is kind of puzzling. With this ticket we are merely kindly asking for some hints where to look for the issue. Our logback.xml files is attached with changed package names not to reveal company internal matters. <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.2.3</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.3</version> </dependency> Labels: configuration logging Priority: Minor Reporter: Oliver Plohmann ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

volunteering for bug fix
by Joseph Tsai 07 Dec '20

07 Dec '20

Hi everyone, I am very new to open source contribution and I want to know if I can contribute to this project in any way. Is there a backlog of bugs where I can try my hands on? I have some experience from working as a junior dev, but I don't think I'm growing as fast as I would like to be. Please let me know if I am not using the maillist the way it is intended to be used. Thank you, Joseph

1 0

[JIRA] Updates for LOGBACK-1543: prudent mode lose efficacy since v1.2.0
by QOS.CH (JIRA) 30 Nov '20

30 Nov '20

logback / LOGBACK-1543 [Open] prudent mode lose efficacy since v1.2.0 ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1543 ============================== Issue created ------------------------------ nico_wen created this issue on 30/Nov/20 4:39 AM Summary: prudent mode lose efficacy since v1.2.0 Issue Type: Bug Affects Versions: 1.2.0 Assignee: Logback dev list Components: logback-core Created: 30/Nov/20 4:39 AM Environment: Since v1.2.0 the prudent mode is almost useless because safeWrite never get really invoked before v1.2.0 {code:java} // OutputStreamAppender.java try { // skip some irrelevant codes... writeOut(event) } catch (IOException ioe) { this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); } // and writeOut is overrided by FileAppender.java @Override protected void writeOut(E event) throws IOException { if (prudent) { safeWrite(event); // here is the point, it ensure write integrity with file lock } else { super.writeOut(event); } }{code} but since v1.2.0, the code was refactored to this {code:java} // OutputStreamAppender.java protected void subAppend(E event) { if (!isStarted()) { return; } try { // skip some irrelevant codes... byte[] byteArray = this.encoder.encode(event); writeBytes(byteArray); // there is no guarantee to safe write } catch (IOException ioe) { this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); } } {code} Priority: Critical Reporter: nico_wen ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

JDK 16 Early Access build 26 is now available
by Rory O'Donnell 27 Nov '20

27 Nov '20

Hi Ceki, OpenJDK 16 Early Access build 26**is now available at http://jdk.java.net/16 * 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>. * Schedule: *JDK 16 Rampdown Phase One Starts on 2020/12/10 [1] * * Features [1]: Most recent Integrations: o Integrated JEP 389: Foreign Linker API (Incubator) <https://openjdk.java.net/jeps/389> with this release. + JEP 389 introduces an API that offers statically-typed, pure-Java access to native code. + This API, together with the JEP 383 <https://openjdk.java.net/jeps/383>, will considerably simplify the otherwise error-prone process of binding to a native library. ** * Release Notes [2] * Changes in recent builds that maybe of interest: o Build 26 + JDK-8202343: *Disable TLS 1.0 and 1.1* + JDK-8251317:**Support for CLDR version 38** + JDK-8212879: Make JVMTI TagMap table concurrent + JDK-8236926: Concurrently uncommit memory in G1 + JDK-8243559: Removed Root Certificates with 1024-bit Keys + JDK-8253459: Argument index of zero or unrepresentable by int throws IllegalFormatException + JDK-8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon o Build 25 + JDK-8247781: Day period support added to java.time formats + JDK-8202471: (ann) Cannot read type annotations on generic receiver type's type variables *[**Reported by ByteBuddy]* + JDK-8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument *[**Reported by JOSM]* + JDK-8256063: Module::getPackages returns the set of package names in this module * JDK 16 - topics of interest o Inside Java Episode 7 “The Vector API” with John Rose and Paul Sandoz + https://inside.java/2020/11/17/podcast-007/ <https://inside.java/2020/11/17/podcast-007/> o Biased locking Obsoletion update + https://inside.java/2020/11/17/biased-locking-obsoletion/ <https://inside.java/2020/11/17/biased-locking-obsoletion/> * Project Loom with Ron Pressler o https://inside.java/2020/11/24/podcast-008/ * Update on 64-bit ARM Support for Oracle OpenJDK and Oracle JDK o https://inside.java/2020/11/12/arm-support-update/ <https://inside.java/2020/11/12/arm-support-update/> Project Lanai Early-Access: EA 7 Build 16-lanai+3-278 <http://jdk.java.net/lanai/> (2020/11/17) * 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> * These EA builds are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. * Please send feedback via e-mail to lanai-dev(a)openjdk.java.net <mailto:lanai-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list <https://mail.openjdk.java.net/mailman/listinfo/lanai-dev>. The Java Cryptographic Roadmap has been updated [3]: * Distrust TLS 1.0 and TLS 1.1 by default o TLS protocol versions 1.0 and 1.1 are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3). This change has been integrated with JDK 16 Early Access build 26. * Upgrade of default algorithms used to encrypt PKCS12 keystores o The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms which were based on RC2, DESede, and SHA-1.This change is already included in JDK 16 Early Access build 23. RgdsRory [1] https://openjdk.java.net/projects/jdk/16/ [2] https://jdk.java.net/16/release-notes [3] https://www.java.com/en/jre-jdk-cryptoroadmap.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (LOGBACK-1542) Fortify scan: dom4j Vulnerability
by QOS.CH (JIRA) 24 Nov '20

24 Nov '20

1 0

[JIRA] Updates for LOGBACK-1542: Fortify scan: dom4j Vulnerability
by QOS.CH (JIRA) 23 Nov '20

23 Nov '20

logback / LOGBACK-1542 [Open] Fortify scan: dom4j Vulnerability ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1542 ============================== Issue created ------------------------------ xavier lamourec created this issue on 23/Nov/20 11:53 AM Summary: Fortify scan: dom4j Vulnerability Issue Type: Bug Assignee: Logback dev list Components: logback-classic Created: 23/Nov/20 11:53 AM Environment: Hi Team, A security issue has been raised by our Fortify scan for the following component: {code}dom4j - XML eXternal Entity (XXE)\{code} *Component Name:* org.dom4j:dom4j *Component Version:* 2.1.1 *Repository:* maven *Instance ID:* B294C4B2311CED0EF0D8F9827BB423C1 *Primary Rule ID:* CVE-2020-10683 *CVSS Base Score:* 7.6 *CVSS Vector:* CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H [https://nvd.nist.gov/vuln/detail/CVE-2020-10683] [https://cwe.mitre.org/data/definitions/611.html|https://cwe.mitre.org/data/…] Priority: Major Reporter: xavier lamourec ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Upgrade slf4j to 1.7.30 for 1.2.x?
by Kris Kalavantavanich 17 Nov '20

17 Nov '20

Hi, What do you think about upgrading slf4j from 1.7.25 to 1.7.30 for version 1.2.x? According to maven for logback-classic, seems like the latest stable version in 1.2.3 which was released nearly 4 years ago. I can help upgrade this as well, however, this will be my first PR for this project; guides are welcomed. Kind regards, Kris

1 0

[JIRA] (LOGBACK-1000) MDC default value is not parsed
by QOS.CH (JIRA) 17 Nov '20

17 Nov '20

1 0

[JIRA] Updates for LOGBACK-1541: Enable Gaffer
by QOS.CH (JIRA) 13 Nov '20

13 Nov '20

logback / LOGBACK-1541 [Open] Enable Gaffer ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1541 ============================== Issue created ------------------------------ Boris created this issue on 13/Nov/20 7:10 PM Summary: Enable Gaffer Issue Type: New Feature Affects Versions: 1.3.0-alpha5 Assignee: Logback dev list Created: 13/Nov/20 7:10 PM Labels: groovy Priority: Major Reporter: Boris Description: In the [news section|https://logback.qos.ch/news.html] it is mentioned that Gaffer was disabled because "all currently available versions of Groovy are incompatible with Java 9". This hasn't been true for years now and the latest Groovy 2.5.13 and Groovy 3.0.5 support even Java 15. Gaffer is probably in use by many projects, one being [Gretty|https://github.com/gretty-gradle-plugin/gretty] It would be nice to enable it again for Logback 1.3.x. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0