- logback-dev - mailman3.qos.ch

JDK 14 - Early Access build 22 is available
by Rory O'Donnell 12 Nov '19

12 Nov '19

Hi Ceki, *OpenJDK builds - JDK 14 *- Early Access build 22 is available at http://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>. * Release notes o https://jdk.java.net/14/release-notes * JEPs targeted to JDK 14, so far: * JEP 345: NUMA-Aware Memory Allocation for G1 <http://openjdk.java.net/jeps/345> was Targeted to JDK 14. * JEP 349: JFR Event Streaming <http://openjdk.java.net/jeps/349> was Integrated. * JEP 361: Switch Expressions (Standard) <http://openjdk.java.net/jeps/361> was Targeted to JDK 14. * JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector <http://openjdk.java.net/jeps/363> was Targeted to JDK 14. * JEP 364: ZGC on macOS <http://openjdk.java.net/jeps/364> was Targeted to JDK 14. * JEP 365: ZGC on Windows <http://openjdk.java.net/jeps/365> moved to Candidate. * JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination <http://openjdk.java.net/jeps/366> was Proposed to target JDK 14. * JEP 367: Remove the Pack200 Tools and API <http://openjdk.java.net/jeps/367> was Targeted to JDK 14. * JEP 368: Text Blocks (Second Preview) <http://openjdk.java.net/jeps/368> moved to Candidate. * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B21%22%3A%3…> *jpackage EA -* Build 14-jpackage+1-67 (2019/11/4) * This is an early access build of JEP 343: Packaging Tool <https://openjdk.java.net/jeps/343>, aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * 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> * Build 14 is now available http://jdk.java.net/jpackage/ * Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (LOGBACK-1491) NPE with Logback 1.3.0-alpha5 in application using module path
by QOS.CH (JIRA) 11 Nov '19

11 Nov '19

1 0

[JIRA] (LOGBACK-1491) NPE with Logback 1.3.0-alpha5 in application using module path
by QOS.CH (JIRA) 11 Nov '19

11 Nov '19

1 0

[JIRA] (LOGBACK-1491) NPE with Logback 1.3.0-alpha5 in application using module path
by QOS.CH (JIRA) 11 Nov '19

11 Nov '19

Patrice Kueny created LOGBACK-1491: -------------------------------------- Summary: NPE with Logback 1.3.0-alpha5 in application using module path Key: LOGBACK-1491 URL: https://jira.qos.ch/browse/LOGBACK-1491 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.3.0-alpha5 Environment: Windows 10 64 bits + AdoptOpenJDK JDK 13.0.0.3 Also with Ubuntu 14.0.4 LTS + zulu13.28.11-ca-jdk13.0.1-linux_amd64.deb logback-classic-1.3.0-alpha5.jar logback-core-1.3.0-alpha5.jar slf4j-api-2.0.0-alpha1.jar Running java application with module path. Reporter: Patrice Kueny Assignee: Logback dev list When running a modular application (with module path) with version 1.3.0-alpha5 of Logback-Classic, I obtain a NullPointerException at the first call to LoggerFactory.getLogger. I had no such problem with the 1.3.0-alpha4 version of Logback-Classic. The problem disappears also if I run the same application in non-modular mode (using the classpath). Below is the stack trace : {quote}Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: java.lang.NullPointerException at ch.qos.logback.core/ch.qos.logback.core.model.processor.DefaultProcessor.traverse(DefaultProcessor.java:114) at ch.qos.logback.core/ch.qos.logback.core.model.processor.DefaultProcessor.traversalLoop(DefaultProcessor.java:39) at ch.qos.logback.core/ch.qos.logback.core.model.processor.DefaultProcessor.process(DefaultProcessor.java:54) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.processModel(GenericConfigurator.java:178) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.playEventsAndProcessModel(GenericConfigurator.java:165) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:151) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:115) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:58) at ch.qos.logback.classic/ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:82) at ch.qos.logback.classic/ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:157) at ch.qos.logback.classic/ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:49) at ch.qos.logback.classic/ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:40) at org.slf4j/org.slf4j.LoggerFactory.bind(LoggerFactory.java:152) at org.slf4j/org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:139) at org.slf4j/org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:418) at org.slf4j/org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:404) at org.slf4j/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:353) at org.slf4j/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:379) at fr.kueny.patrice.lab/fr.kueny.patrice.lab.ihm.LabStarter.<init>(LabStarter.java:57) at fr.kueny.patrice.lab/fr.kueny.patrice.lab.ihm.LabStarter.main(LabStarter.java:46) {quote} The problem seems not related to the content of the logback.xml file because I obtain the same result with the default logback.xml file (logback-examples/src/main/resources/chapters/configuration/sample0.xml). The problem seems to be related to the method ch.qos.logback.core.joran.GenericConfigurator::playEventsAndProcessModel introduced in the 1.3.0-alpha5 version. I suspect a violation of java modules access rights. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

helpful to warn when not configured?
by Roger Pack 06 Nov '19

06 Nov '19

It might be helpful to, if no logback configuration files are found at runtime, output something mentioning it, like a warning: "logback: no configuration files found, defaulting to BasicConfigurator DEBUG level to STDOUT" As it is sometimes you get DEBUG logs showing up on the screen and have no idea what's occurring...or what's misconfigured. Thanks! -roger-

2 2

[JIRA] (LOGBACK-1422) Deadlock with logging
by QOS.CH (JIRA) 04 Nov '19

04 Nov '19

1 0

[JIRA] (LOGBACK-1490) Document change of "timestamp" attribute to "name" from "key"
by QOS.CH (JIRA) 31 Oct '19

31 Oct '19

Ceki Gülcü created LOGBACK-1490: ----------------------------------- Summary: Document change of "timestamp" attribute to "name" from "key" Key: LOGBACK-1490 URL: https://jira.qos.ch/browse/LOGBACK-1490 Project: logback Issue Type: Task Reporter: Ceki Gülcü Assignee: Ceki Gülcü Fix For: 1.3.0-alpha6 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/logback] cc0d73: remove superflous session.setDebug call
by Ceki Gulcu 31 Oct '19

31 Oct '19

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: cc0d7394faf2525a43f967f8960d54ebefe30b2c https://github.com/qos-ch/logback/commit/cc0d7394faf2525a43f967f8960d54ebef… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-10-31 (Thu, 31 Oct 2019) Changed paths: M logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java Log Message: ----------- remove superflous session.setDebug call

1 0

[JIRA] (LOGBACK-1422) Deadlock with logging
by QOS.CH (JIRA) 30 Oct '19

30 Oct '19

1 0

[JIRA] (LOGBACK-1422) Deadlock with logging
by QOS.CH (JIRA) 29 Oct '19

29 Oct '19

1 0