February 2019 - logback-dev

removing context selectors will break our libraries and applications
by Garret Wilson 28 Apr '19

28 Apr '19

Hi, I've been pretty deep inside the Logback code. In fact I wrote a comprehensive explanation on the bootstrap procedure here: https://stackoverflow.com/a/38317149/421049 We've created a library called Csar that allows one to configure various configuration "contexts" within the same JVM, for a program that has different locales at the same time, or different logging configurations for different users, etc. I explain this all at https://dzone.com/articles/creating-local-globals-with-csar . Our Clogr library used Csar to allow different logging configurations (or even different logging libraries!) to be set up for different parts of the application. (Imagine a server with different user sessions, each session being logged to a different file.) We got this working great for Logback. In fact we integrated it into our software development course; read about it here: https://clogr.io/learn (See the section on Clogr and compartmentalized configurations with Logback at the bottom.) The problem is that the initial bootstrap sequence of Logback was brittle, relying on a static class that could appear across modules. The appearance of the Java 9+ module system prohibits this altogether. But I had already created a ticket https://jira.qos.ch/browse/LOGBACK-1196 for how to fix this, long before the Java system was released, using the standard service provider mechanism. But now I see at https://logback.qos.ch/news.html that Logback will remove contexts altogether. This will break our ability to configure loggers separately in our application, and to use Clogr to manage them. Why remove this? There was nothing wrong with the simple context selection. The problem was how it was configured, using a static classes that had to be placed in a module outside its package. Just implement https://jira.qos.ch/browse/LOGBACK-1196, please. Don't break our application. I even provide much of the code to do this at LOGBACK-1196. What can we do to keep this from being removed and breaking our library? Why do we need to remove it in the first place? Why not fix it? (Ironically I was just told that Log4j 2 supports contexts, so maybe our application will have to switch back to Log4j. But I would prefer to have Clogr support both Logback and Log4j 2. There is no reason to remove this capability from Logback.) As I mentioned two years ago in LOGBACK-1196, I'm willing to contribute to fixing this. Let me know how to go forward. Thanks, Garret Wilson President GlobalMentor, Inc.

2 3

beg for core user case about logback
by froest 21 Feb '19

21 Feb '19

Hello Everyone, I want to study the source code of logback, who can provide the core user case about logback to me, Thanks very much.

1 0

(no subject)
by froest 21 Feb '19

21 Feb '19

Hello Everyone, I want to study the source code of logback, who can provide the core user case about logback to me, Thanks very much.

1 0

[JIRA] (LOGBACK-1100) Skip SubstituteLogger from caller data
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

1 0

JDK 12: First Release Candidate available
by Rory O'Donnell 18 Feb '19

18 Feb '19

Hi Ceki, **OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at : - jdk.java.net/12/* **JDK 12: First Release Candidate [1]** * Per the JDK 12 schedule [2], we are now in Release Candidate Phase. * The stabilization repository, jdk/jdk12, is open for P1 bug fixes per the JDK Release Process (JEP 3) [3]. * All changes require approval via the Fix-Request Process [4]. * Release note additions since last email o Build 31 - can_pop_frame and can_force_early_return capabilities are disabled if JVMCI compiler is used (JDK-8218025 <https://bugs.openjdk.java.net/browse/JDK-8218025>) The JVMTI |can_pop_frame| and |can_force_early_return| capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (|PopFrame| and |ForceEarlyReturnXXX| functions) is not available to JVMTI agents. This issue is being fixed via JDK-8218885 <https://bugs.openjdk.java.net/browse/JDK-8218885> [https://bugs.openjdk.java.net/browse/JDK-8218885 <https://bugs.openjdk.java.net/browse/JDK-8218885>]. o Build 28: JDK-8212233 <https://bugs.openjdk.java.net/browse/JDK-8212233> : javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module." * Changes in this build. <http://hg.openjdk.java.net/jdk/jdk12/log?rev=reverse%28%22jdk-12%2B31%22%3A…> **OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at : - jdk.java.net/13/* * 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>. * Release Notes updates * Build 8 o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() are unified across the platforms (JDK-8214918 <https://bugs.openjdk.java.net/browse/JDK-8214918>) o The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider. (JDK-8217835 <https://bugs.openjdk.java.net/browse/JDK-8217835>) * Build 7 o Change DOM parser to not resolve EntityReference and add Text node with DocumentBuilderFactory.setExpandEntityReferences(false) (JDK-8206132 <https://bugs.openjdk.java.net/browse/JDK-8206132>) * Build 6 o Base64.Encoder and Base64.Decoder methods can throw OutOfMemoryError (JDK-8210583 <https://bugs.openjdk.java.net/browse/JDK-8210583>) * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B7%22%3A%3A…> * FOSS Bugs fixed in recent builds o Build 6 : JDK-8216970 <https://bugs.openjdk.java.net/browse/JDK-8216970> : condy causes JVM crash o Build 7: JDK-8215577 <https://bugs.openjdk.java.net/browse/JDK-8215577> : Remove javadoc support for HTML 4 Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html [2] http://openjdk.java.net/projects/jdk/12/#Schedule [3] http://openjdk.java.net/jeps/3 [4] http://openjdk.java.net/jeps/3#Fix-Request-Process -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1374) Increase timestamp resolution
by QOS.CH (JIRA) 12 Feb '19

12 Feb '19

1 0

[JIRA] (LOGBACK-1374) Increase timestamp resolution
by QOS.CH (JIRA) 11 Feb '19

11 Feb '19

1 0

[JIRA] (LOGBACK-1457) Avoid instantiating unused appenders
by QOS.CH (JIRA) 06 Feb '19

06 Feb '19

1 0

[JIRA] (LOGBACK-1457) Avoid instantiating unused appenders
by QOS.CH (JIRA) 06 Feb '19

06 Feb '19

Gili created LOGBACK-1457: ----------------------------- Summary: Avoid instantiating unused appenders Key: LOGBACK-1457 URL: https://jira.qos.ch/browse/LOGBACK-1457 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.2.3 Environment: If {{logback.xml}} contains a FILE appenders, but the parent directories cannot be created then we get a runtime exception. Example: {code:java} 18:49:04,076 |-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - openFile(null,true) call failed. java.io.FileNotFoundException: log/auction-house-cluster.2019-02-06.log (No such file or directory) at java.io.FileNotFoundException: log/auction-house-cluster.2019-02-06.log (No such file or directory) at java.base/java.io.FileOutputStream.open0(Native Method) at java.base/java.io.FileOutputStream.open(FileOutputStream.java:298) at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:237) at ch.qos.logback.core.recovery.ResilientFileOutputStream.<init>(ResilientFileOutputStream.java:26) at ch.qos.logback.core.FileAppender.openFile(FileAppender.java:204) at ch.qos.logback.core.FileAppender.start(FileAppender.java:127) at ch.qos.logback.core.rolling.RollingFileAppender.start(RollingFileAppender.java:100) at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90) at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383) at com.company.Testcase.<clinit>(Testcase.java:16) {code} However, when we run under Docker we want to keep the appender definition in place but direct output to STDOUT instead. The problem is that Logback initializes the appender even when it isn't in use, consequently we get an error even when nothing is wrong. There are workarounds, such as conditional blocks, but reduce the readability of the configuration file. Please avoid initializing unused appenders. Reporter: Gili Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0