January 2022 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-534: Improve error handling for situations where paths is null in findPossibleStaticLoggerBinderPathSet()
by QOS.CH (JIRA) 12 Jan '22

12 Jan '22

SLF4J / SLF4J-534 [Open] Improve error handling for situations where paths is null in findPossibleStaticLoggerBinderPathSet() ============================== 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/SLF4J-534 ============================== Issue created ------------------------------ Oliver Lietz created this issue on 12/Jan/22 9:37 AM Summary: Improve error handling for situations where paths is null in findPossibleStaticLoggerBinderPathSet() Issue Type: Improvement Affects Versions: 1.7.32 Assignee: SLF4J developers list Components: Core API Created: 12/Jan/22 9:37 AM Environment: NPE in JPMS/OSGi application: {noformat} Failed to instantiate SLF4J LoggerFactory Reported exception: java.lang.NullPointerException: Cannot invoke "java.util.Enumeration.hasMoreElements()" because "paths" is null at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.findPossibleStaticLoggerBinderPathSet(LoggerFactory.java:310) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.bind(LoggerFactory.java:146) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.ops4j.pax.logging.internal.Activator.start(Activator.java:112) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:849) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.Felix.activateBundle(Felix.java:2429) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.Felix.startBundle(Felix.java:2335) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) at java.base/java.lang.Thread.run(Thread.java:833) ERROR: Bundle org.ops4j.pax.logging.pax-logging-api [33] Error starting atomos:application:file:///[...]/de.bildschirmarbeiter.aem.toolbox.package/target/jlink/mp/pax-logging-api-2.0.15-SNAPSHOT.jar (org.osgi.framework.BundleException: Activator start error in bundle org.ops4j.pax.logging.pax-logging-api [33].) java.lang.IllegalStateException: Unexpected initialization failure at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.bind(LoggerFactory.java:175) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.ops4j.pax.logging.internal.Activator.start(Activator.java:112) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:849) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.Felix.activateBundle(Felix.java:2429) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.Felix.startBundle(Felix.java:2335) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566) at org.apache.felix.framework@7.0.3/org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: java.lang.NullPointerException: Cannot invoke "java.util.Enumeration.hasMoreElements()" because "paths" is null at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.findPossibleStaticLoggerBinderPathSet(LoggerFactory.java:310) at ModuleConnectLoader-org.ops4j.pax.logging.pax-logging-api/org.ops4j.pax.logging.pax-logging-api@2.0.15.SNAPSHOT/org.slf4j.LoggerFactory.bind(LoggerFactory.java:146) ... 10 more {noformat} Error should be more descriptive. Priority: Minor Reporter: Oliver Lietz Severity: enhancement ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-533: Add support for {{LocationAwareLogger}} to {{DefaultLoggingEventBuilder}}'s fallback path
by QOS.CH (JIRA) 07 Jan '22

07 Jan '22

SLF4J / SLF4J-533 [Open] Add support for {{LocationAwareLogger}} to {{DefaultLoggingEventBuilder}}'s fallback path ============================== 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/SLF4J-533 ============================== Issue created ------------------------------ ExE Boss created this issue on 07/Jan/22 11:15 PM Summary: Add support for {{LocationAwareLogger}} to {{DefaultLoggingEventBuilder}}'s fallback path Issue Type: Bug Affects Versions: 2.0.0-alpha5, 2.0.0-alpha6 Assignee: SLF4J developers list Components: Core API Created: 07/Jan/22 11:15 PM Priority: Major Reporter: ExE Boss Description: Currently, if a [{{LocationAwareLogger}}|https://www.slf4j.org/api/org/slf4j/spi/LocationAwareLogger.html] doesn't also implement [{{LoggingEventAware}}|https://www.slf4j.org/api/org/slf4j/spi/LoggingEventAware.html], then {{DefaultLoggingEventBuilder}} discards caller boundary information, even though [{{LocationAwareLogger::log}}|https://www.slf4j.org/api/org/slf4j/spi/LocationAwareLogger.html#log(org.slf4j.Marker,java.lang.String,int,java.lang.String,java.lang.Object%5B%5D,java.lang.Throwable)] accepts a {{fqcn}} parameter. h2. Success metrics {{DefaultLoggingEventBuilder}} correctly passes caller boundary information to {{LocationAwareLogger::log}}. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-526: Idea for fluent API improvement
by QOS.CH (JIRA) 06 Jan '22

06 Jan '22

SLF4J / SLF4J-526 [Open] Idea for fluent API improvement ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-526 ============================== 1 comment ------------------------------ Adrian Shum on 06/Jan/22 11:35 PM I think a {{Consumer<LogEventBuilder>}} should do the work? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-526: Idea for fluent API improvement
by QOS.CH (JIRA) 06 Jan '22

06 Jan '22

SLF4J / SLF4J-526 [Open] Idea for fluent API improvement ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-526 ============================== 1 comment ------------------------------ Ceki Gülcü on 06/Jan/22 2:50 PM Hi [~adrianshum] What does {{log->\{log.message(Temperature of {} rise from {} to {}", ...)}}} return? Asked differently, what is the input type of {{atDebug()}}? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-526: Idea for fluent API improvement
by QOS.CH (JIRA) 06 Jan '22

06 Jan '22

SLF4J / SLF4J-526 [Open] Idea for fluent API improvement ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-526 ============================== 1 comment ------------------------------ Adrian Shum on 06/Jan/22 7:54 AM I do understand the concern. For me, it is also a trade-off for code readability. Code becoming harder to read as our brains have been trained to read the logging by message-with-placeholder, followed by values. Given fluent API are aimed for construction in more dynamic way, we may still face problem that the code will not have {{.log(message)}} called. I don't see reason why we couldn't provide both options to users: They could normally use {{.log(message)}} if they want a "safer" practice, but they could still choose another approach if they want readability. Another idea, although may look less elegant, is to make use of lambda to even omitting needs of calling {{log()}} : {code:java} logger.atDebug(l->l.message(Temperature of {} rise from {} to {}") .arg(country) .arg(oldTemp) .arg(newTemp)); // More dynamic logging event construction, where .log(...) could be missed even easier logger.atDebug(l->{ l.message(Temperature of {} rise from {} to {}") .arg(country) .arg(oldTemp) .arg(newTemp); for (Entry<String, String> e: myMap) { l.addKeyValue(e.getKey(), e.getValue()); } }); {code} Apart from omitting need of needing user to call {{.log()}} (hence, safer API), this also allows potential optimization in future, to reuse same (or a ThreadLocal one?) Log Event Builder across multiple calls, instead of creating new builder every time. (Can help on the lambda approach too if you think it looks fine) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-532: Upgrade slf4j-log4j12 log4j dependency version to 2.17.0 and above
by QOS.CH (JIRA) 05 Jan '22

05 Jan '22

SLF4J / SLF4J-532 [Resolved] Upgrade slf4j-log4j12 log4j dependency version to 2.17.0 and above ============================== Here's what changed in this issue in the last few minutes. There are 2 updates, 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-532 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 05/Jan/22 1:05 PM Resolution: Won't Fix Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 05/Jan/22 1:05 PM slf4j-log4j12 is an adapter for log4j 1.x. Don't be fooled by the name, log4j 2.x is very different project. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-532: Upgrade slf4j-log4j12 log4j dependency version to 2.17.0 and above
by QOS.CH (JIRA) 05 Jan '22

05 Jan '22

SLF4J / SLF4J-532 [Open] Upgrade slf4j-log4j12 log4j dependency version to 2.17.0 and above ============================== 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/SLF4J-532 ============================== Issue created ------------------------------ Swyrik Thupili created this issue on 05/Jan/22 12:48 PM Summary: Upgrade slf4j-log4j12 log4j dependency version to 2.17.0 and above Issue Type: Bug Affects Versions: 1.7.20, 1.7.30, 1.7.x Assignee: SLF4J developers list Created: 05/Jan/22 12:48 PM Environment: Please update the log4j 2 version to the log4j 2.17.0 and above. As the current versions are susceptible to [CVE-2021-44832|https://github.com/advisories/GHSA-8489-44mv-ggj8] Security Vulnerability. Priority: Major Reporter: Swyrik Thupili ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should suppot stack values identified by key
by QOS.CH (JIRA) 02 Jan '22

02 Jan '22

SLF4J / SLF4J-531 [Open] MDC should suppot stack values identified by key ============================== Here's what changed in this issue in the last few minutes. This issue has been created View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-531 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 02/Jan/22 6:38 PM Summary: MDC should suppot stack values identified by key Issue Type: New Feature Assignee: Ceki Gülcü Components: Core API Created: 02/Jan/22 6:38 PM Fix Versions: 2.0.0-alpha6 Priority: Major Reporter: Ceki Gülcü Description: MDC should support stack type values identified by key. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0