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

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 13 Apr '22

13 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== 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-531 ============================== 1 comment ------------------------------ Piotr P. Karwasz on 14/Apr/22 12:32 AM [~ceki], Log4j 2.x has a single stack of strings available, therefore all the remaining keyed stacks need to be stored as strings. I submitted a functional implementation for Log4j2 as [PR #820|https://github.com/apache/logging-log4j2/pull/820], but I can be easily adapt it as an SLF4J default method implementation. The key assumption (no pun intended) in that proposal is that users should not use the same keys for their string and stack values, which is not a heavy restriction and can be added to the {{MDCAdapter}} contract. I am not sure how many active logging frameworks are still there, but JBoss Log Manager would probably also prefer to share the key namespace between string and stack values (cf. [MDC|https://github.com/jboss-logging/jboss-logmanager/blob/main/core/src/ma…] Since most users will probably use a single stack of strings, I might also suggest to add to the interface some methods without a {{key}} parameter that would use default key of the SLF4J implementation (the NDC for Log4j2 and JBoss Log Manager). ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-547: The deque API is not easily distinguished
by QOS.CH (JIRA) 13 Apr '22

13 Apr '22

SLF4J / SLF4J-547 [Open] The deque API is not easily distinguished ============================== 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-547 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 13/Apr/22 7:57 PM Summary: The deque API is not easily distinguished Issue Type: Sub-task Assignee: SLF4J developers list Created: 13/Apr/22 7:57 PM Priority: Major Reporter: Ceki Gülcü Description: The "byKey" suffix is not much help. Adding a "deque" prefix might be a better alternative. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 13 Apr '22

13 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== 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-531 ============================== 1 comment ------------------------------ Ceki Gülcü on 13/Apr/22 7:52 PM [~pkarwasz] I had not thought of the same key situation for string values and stack values. The underlying assumption was that string values and stack values are supported by separate data structures accessed via separate methods. It follows that you can use the same key for string values and stack values as they would be handled by different supporting data structures. The MDC is a single access point to both "APIs". ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-531: MDC should support stack values identified by key
by QOS.CH (JIRA) 13 Apr '22

13 Apr '22

SLF4J / SLF4J-531 [Open] MDC should support stack values identified by key ============================== 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-531 ============================== 1 comment ------------------------------ Piotr P. Karwasz on 13/Apr/22 7:20 PM Hello [~ceki], Can we assume that the same key can not be used for string values and stack values? That would help supporting it in alternative SLF4J implementations. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-546: Fluent logging API doesn't populate timestamp with Reload4JLogger
by QOS.CH (JIRA) 01 Apr '22

01 Apr '22

SLF4J / SLF4J-546 [Open] Fluent logging API doesn't populate timestamp with Reload4JLogger ============================== 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-546 ============================== Issue created ------------------------------ Joseph Walton created this issue on 01/Apr/22 12:36 PM Summary: Fluent logging API doesn't populate timestamp with Reload4JLogger Issue Type: Bug Affects Versions: 2.0.0-alpha7 Assignee: SLF4J developers list Components: Implementations Created: 01/Apr/22 12:36 PM Priority: Major Reporter: Joseph Walton Description: If my log format includes a timestamp with {{%d}}: {noformat} log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d %m%n {noformat} and I log with both the traditional and fluent APIs: {noformat} log.info("A simple message"); log.atInfo().log("Fluent message"); {noformat} then the timestamp isn't populated for the fluent-logged message: {noformat} 2022-04-01 21:34:37,776 A simple message 1970-01-01 10:00:00,000 Fluent message {noformat} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-168: Feature-Request: allow Object as value in MDC.put
by QOS.CH (JIRA) 01 Apr '22

01 Apr '22

SLF4J / SLF4J-168 [Open] Feature-Request: allow Object as value in MDC.put ============================== 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-168 ============================== 1 comment ------------------------------ Joseph Walton on 01/Apr/22 9:25 AM I've run into the same mismatch. However, Log4j 2's [ThreadContext|https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/ap…] moves to a [{{String}} for the value to be put|https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/loggi…] Is there a notable backing implementation that keeps this as {{Object}}?, or would this be better handled through {{LoggingEventBuilder}}'s [addKeyValue|https://www.slf4j.org/api/org/slf4j/spi/LoggingEventBuilder.htm… ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0