June 2022 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1645) Disable pattern programatically in current thread.
by QOS.CH (JIRA) 28 Jun '22

28 Jun '22

1 0

[JIRA] (LOGBACK-1644) ch.qos.logback.core.sift.SiftingAppenderBase#stop method reports NullPointerException
by QOS.CH (JIRA) 28 Jun '22

28 Jun '22

1 0

[JIRA] Updates for LOGBACK-1645: Disable pattern programatically in current thread.
by QOS.CH (JIRA) 27 Jun '22

27 Jun '22

logback / LOGBACK-1645 [Open] Disable pattern programatically in current thread. ============================== 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-1645 ============================== Issue created ------------------------------ Martin created this issue on 27/Jun/22 4:01 PM Summary: Disable pattern programatically in current thread. Issue Type: Improvement Assignee: Logback dev list Components: logback-core Created: 27/Jun/22 4:01 PM Labels: logging Priority: Minor Reporter: Martin Description: Working with logger is essential for troubleshooting but sometime there is way too much debug logs. Sometime they are too verbose but still needed. I came across a issue with disk spaces and the logs were top blame. I want to propose a simple feature to the logger. Let say I have a really fast and verbose thread algorithm. {code:java} 2022-06-10 14:27:23:123 -0400 [normal] DEBUG org.slf4j.impl.App - Calling internal process 2022-06-10 14:27:23:123 -0400 [normal] DEBUG org.slf4j.impl.App - Clean up list from empty or null string 2022-06-10 14:27:23:123 -0400 [normal] DEBUG org.slf4j.impl.App - Removing : "" 2022-06-10 14:27:23:123 -0400 [normal] DEBUG org.slf4j.impl.App - Removing : "null" <...> 2022-06-10 14:27:23:123 -0400 [normal] INFO org.slf4j.impl.App - Listing entries 2022-06-10 14:27:23:124 -0400 [compact] DEBUG org.slf4j.impl.App - Return to Normal log {code} I propose to include a flag that will keep the logging and avoid duplicated the pattern. I want to: Use ThreadLocal to avoid impacting all the other logs. Enable programmatically to be specific for known verbose path only Keep the initial pattern of the first log call. Enable it only for debug level, other level will continue to be log with the pattern. Closable to be easy to use. Result must be something like this: {code:java} 2022-06-10 14:27:23:119 -0400 [compact] INFO org.slf4j.impl.App - Enabling compact logging 2022-06-10 14:27:23:120 -0400 [compact] INFO org.slf4j.impl.App - Listing entries 2022-06-10 14:27:23:120 -0400 [compact] DEBUG org.slf4j.impl.App - Calling internal process Clean up list from empty or null string Removing : "" Removing : "null" <...> 2022-06-10 14:27:23:120 -0400 [compact] DEBUG org.slf4j.impl.App - Return to Normal log {code} The code will be use like this: {code:java} @Slf4j public class App { public void publicCall( List<String> list ) { log.info("Enabling compact logging"); try (AutoCloseable ignored = ((CompactLogger)log).beginCompactLogging()) { processList(list); } catch (Exception e) { log.error("Process issue", e); } log.debug("Return to Normal log"); } }{code} Related to: https://jira.qos.ch/browse/SLF4J-552. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1612) jul LevelChangePropagator is inconsistent with SLF4JBridgeHandler
by QOS.CH (JIRA) 18 Jun '22

18 Jun '22

1 0

[JIRA] Updates for LOGBACK-1644: ch.qos.logback.core.sift.SiftingAppenderBase#stop method reports NullPointerException
by QOS.CH (JIRA) 14 Jun '22

14 Jun '22

logback / LOGBACK-1644 [Open] ch.qos.logback.core.sift.SiftingAppenderBase#stop method reports NullPointerException ============================== 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-1644 ============================== Issue created ------------------------------ Changjun Xiao created this issue on 14/Jun/22 11:35 AM Summary: ch.qos.logback.core.sift.SiftingAppenderBase#stop method reports NullPointerException Issue Type: Bug Affects Versions: 1.2.11, 1.3.0-alpha16 Assignee: Logback dev list Attachments: SiftingAppenderBase-NullPointerException.txt Components: logback-core Created: 14/Jun/22 11:35 AM Environment: jdk1.8.0_192 CentOS Linux release 7.3.1611 Labels: siftingAppender Priority: Major Reporter: Changjun Xiao Description: The `ch.qos.logback.core.sift.SiftingAppenderBase#stop` method lacks `isStarted()` judgment. If this method is called without `start()`, a `NullPointerException` will be reported because `appenderTracker` is not initialized. It can be solved by adding `isStarted()` judgment. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1643) gpg key without user id; can't verify logback-classic-1.2.11.pom
by QOS.CH (JIRA) 08 Jun '22

08 Jun '22

1 0

[JIRA] (LOGBACK-1623) NPE in ThrowableProxy in 1.2.11 if extractSupressedThrowables returns null
by QOS.CH (JIRA) 08 Jun '22

08 Jun '22

1 0

[JIRA] Updates for LOGBACK-1643: gpg key without user id; can't verify logback-classic-1.2.11.pom
by QOS.CH (JIRA) 07 Jun '22

07 Jun '22

logback / LOGBACK-1643 [Open] gpg key without user id; can't verify logback-classic-1.2.11.pom ============================== 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-1643 ============================== Issue created ------------------------------ Jeff Gaston created this issue on 07/Jun/22 10:04 PM Summary: gpg key without user id; can't verify logback-classic-1.2.11.pom Issue Type: Bug Affects Versions: 1.2.11 Assignee: Logback dev list Attachments: logback-classic-1.2.11.pom, logback-classic-1.2.11.pom.asc, verification-keyring.keys Created: 07/Jun/22 10:04 PM Environment: Ubuntu Priority: Major Reporter: Jeff Gaston Description: We're observing that logback-classic-1.2.11.pom doesn't pass gpg verification (or [Gradle verification|https://github.com/gradle/gradle/issues/20958] ) and it seems to be because `gpg: key 2C7B12F2A511E325: new key but contains no user ID - skipped` See this output: ``` $ gpg --verify logback-classic-1.2.11.pom.asc gpg: assuming signed data in 'logback-classic-1.2.11.pom' gpg: Signature made Sat 05 Mar 2022 04:14:24 PM EST gpg: using RSA key 2C7B12F2A511E325 gpg: Can't check signature: No public key /tmp $ gpg --receive-keys 2C7B12F2A511E325 gpg: key 2C7B12F2A511E325: new key but contains no user ID - skipped gpg: Total number processed: 1 gpg: w/o user IDs: 1 ``` ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0