- 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

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

22 Mar '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 22/Mar/22 12:53 AM @ceki+jira Great to know! :) some other ideas for the initial proposal, which I dunno if make sense: * By default, return a thread-local instance of builder which can ** reduce cost of allocating new one every time ** could provide detection of missing log(), by checking if builder.log() has been called at atXxx() ** Although above should serve 99.9% of use case, if someone really need a separate instance of builder (e.g. they are building up multiple log messages at the same time), we could provide an extra atXxx() method which will return new instance * It may make sense to allow providing message/messageProvider at the atXxx() method directly. So to demonstrate the idea: {code:java} ////////////////////////////////////////////////////////////////////// // reduced builder allocation ////////////////////////////////////////////////////////////////////// logger.atDebug().message("first log {}").arg(a1).log(); // returning a thread local instance of builder logger.atDebug().message("second log {}").arg(a2).log(); // the builder instance we use here will be the same as above logger.atDebug().message("forgot to call log()"); logger.atDebug().message("fourth log{}").log(); // when we call atDebug(), it check if the builder is "clear". If not, give a warning or automatically call the log()? ////////////////////////////////////////////////////////////////////// // if people really wants to have multiple instances of builder ////////////////////////////////////////////////////////////////////// outputBuilder = logger.atDebug(AllocationType::NEW); // default one is SINGLETON maybe, which means single one per-thread errorBuilder = logger.atDebug(AllocationType::NEW); // bunch of logic to construct log by outputBuilder and errorBuilder outputBuilder.log(); errorBuilder.log(); (of course, user will not enjoy the auto-detection of missing log()) ////////////////////////////////////////////////////////////////////// // we could provide message directly ////////////////////////////////////////////////////////////////////// logger.atDebug("temperature is {}").arg(temperature).log(); {code} ============================== 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) 18 Mar '22

18 Mar '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 18/Mar/22 3:14 PM [~adrianshum] Thank you for the PR. I am quite interested in implementing your initial proposal and have [asked for feedback|http://mailman.qos.ch/pipermail/slf4j-dev/2022-March/005825.html] on the slf4j-dev@ mailing list. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-545: slf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.format()
by QOS.CH (JIRA) 18 Mar '22

18 Mar '22

SLF4J / SLF4J-545 [Resolved] slf4j-jdk-platform-logging - SLF4JPlatformLogger should use java.text.MessageFormat - not String.format() ============================== 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-545 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 18/Mar/22 2:59 PM Resolution: Duplicate Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 18/Mar/22 2:59 PM Duplicate of SLF4J-529 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Planned/possible fluent API change
by Ceki Gülcü 18 Mar '22

18 Mar '22

Hello all, In SLF4J-526, Adrian Shum proposed to modify the fluent API. Currently, to emit a debug message with two parameters, one has to write the following logger.atDebug() .addArgument(country).addArgument(oldTemp).addArgument(newTemp) .log("Temperature of {} rise from {} to {}"); He proposes that the API be changed to logger.atDebug() .message("Temperature of {} rise from {} to {}" ) .arg(country).arg(oldTemp).arg(newTemp).log(); I think his suggestion makes sense with one inconvenience. In case the user forgets to call the no-argument log() method, then nothing will happen, i.e. no logging will occur. With the current API, it is harder for the user to forget the log(String) method containing the message content. Before going forward with Adrian's proposal or not, I would like to receive input by interested parties. Best regards, [1] https://jira.qos.ch/browse/SLF4J-526 -- Ceki Gülcü

1 0