- slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-525: slf4j-api initialization should be thread safe
by QOS.CH (JIRA) 26 Nov '21

26 Nov '21

SLF4J / SLF4J-525 [Open] slf4j-api initialization should be thread safe ============================== 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-525 ============================== Issue created ------------------------------ weipan created this issue on 26/Nov/21 4:09 AM Summary: slf4j-api initialization should be thread safe Issue Type: Bug Affects Versions: 1.7.32 Assignee: SLF4J developers list Attachments: image-2021-11-26-11-02-07-612.png, image-2021-11-26-11-02-41-800.png, image-2021-11-26-11-03-21-460.png, image-2021-11-26-11-04-34-942.png, image-2021-11-26-11-05-35-839.png, image-2021-11-26-11-08-38-968.png Created: 26/Nov/21 4:09 AM Environment: centos8_aarch64 Priority: Major Reporter: weipan Description: when I mvn test in slf4j(a)1.7.32,it happened: !image-2021-11-26-11-02-07-612.png|thumbnail! !image-2021-11-26-11-02-41-800.png|thumbnail! !image-2021-11-26-11-03-21-460.png|thumbnail! I want to know what happens in this function: !image-2021-11-26-11-04-34-942.png|thumbnail! It returns a value of eventCount.get(), which is shown above as 2305 (not fixed) but later as 2275 and passed to the recordedEventCount variable. The expectedEventCount variable is directly determined by the eventCount.get() and extraLogEvents() functions. The return value of extraLogEvents() is 0. Therefore, expectedEventCount is directly transferred by the eventCount.get() function and returns 2305. The final result is 2305 < = 2275 + 16. The key information is why eventCount.get() changes. Check the log code related to eventCount.get()： !image-2021-11-26-11-05-35-839.png|thumbnail! The value of expectedEventCount must be smaller than the value of recordedEventCount+LENIENCY_COUNT, which indicates the tolerance value. That is, the tolerance value range should be extended. However, the initialization should be thread-safe. As a result, the tolerance value range is limited. As a result, an error is reported.So if I can change it this way: !image-2021-11-26-11-08-38-968.png|thumbnail! ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-524: Please add the SLF4J Release information to the 1st message print to the console
by QOS.CH (JIRA) 26 Oct '21

26 Oct '21

SLF4J / SLF4J-524 [Open] Please add the SLF4J Release information to the 1st message print to the console ============================== 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-524 ============================== 1 comment ------------------------------ Ceki Gülcü on 26/Oct/21 9:06 PM Possible implementation via: {code:java} this.getClass().getPackage().getImplementationVersion(); {code} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-524: Please add the SLF4J Release information to the 1st message print to the console
by QOS.CH (JIRA) 26 Oct '21

26 Oct '21

SLF4J / SLF4J-524 [Open] Please add the SLF4J Release information to the 1st message print to the console ============================== 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-524 ============================== Issue created ------------------------------ Jehoschua created this issue on 26/Oct/21 8:19 PM Summary: Please add the SLF4J Release information to the 1st message print to the console Issue Type: Improvement Affects Versions: 2.0.0-alpha4 Assignee: SLF4J developers list Components: Core API Created: 26/Oct/21 8:19 PM Environment: Not relevant Labels: suggestion Priority: Minor Reporter: Jehoschua Description: Hello thanks a lot for sharing your great work! When we work with different projects, it is often a mystery which SLF4J version is active if we get this kind of message: {{SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".}} {{SLF4J: Defaulting to no-operation (NOP) logger implementation}} {{SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.}} Could you please write the SLF4J release information in the first message that is printed to the console? I guess that this additional information does not bother, but can be a good help over and over again. Thanks a lot, kind regards, Thomas ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-471: CharSequence and varargs
by QOS.CH (JIRA) 21 Oct '21

21 Oct '21

SLF4J / SLF4J-471 [Open] CharSequence and varargs ============================== 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-471 ============================== 1 comment ------------------------------ Endre Stølsvik on 21/Oct/21 11:47 PM One basic reason for why CharSequence is better, is that a StringBuilder is a CharSequence. Right now, I am constructing a message with lots of ifs-and-buts, and then when I want to log it, i _have to_ do .toString() on it, creating a new object with a new char-array. But the other is what OP mentions: You might want to pre-allocate log char arrays for a thread, and then reuse them - avoiding object creations. This would actually work nicely with StringBuilders, using setLength(0) to "clear" them. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-523: IllegalArgumentException with tag name having 23 characters
by QOS.CH (JIRA) 07 Oct '21

07 Oct '21

SLF4J / SLF4J-523 [Open] IllegalArgumentException with tag name having 23 characters ============================== 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-523 ============================== Issue created ------------------------------ Yongsik Moon created this issue on 07/Oct/21 6:57 AM Summary: IllegalArgumentException with tag name having 23 characters Issue Type: Bug Affects Versions: 1.7.30 Assignee: SLF4J developers list Attachments: image-2021-10-07-15-56-27-225.png Components: slf4j-android Created: 07/Oct/21 6:57 AM Environment: * Software platform : Android 4.4 and 7 * slf4j-api:1.7.10 * slf4j-android: 1.7.30 or higher * tag name : "ChannelServerSocket_١٠٠" (in Arabic, the length is 23) Priority: Major Reporter: Yongsik Moon Severity: major Description: With the tag name "ChannelServerSocket_١٠٠", IllegalArgumentException is thrown. I think JNI uses UTF-8 string to count length. !image-2021-10-07-15-56-27-225.png|width=604,height=219! ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[qos-ch/slf4j] 98f1f2: fix typo in version name
by Ceki Gulcu 27 Sep '21

27 Sep '21

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 98f1f2f46533eba4945dda995225cf3c4017a075 https://github.com/qos-ch/slf4j/commit/98f1f2f46533eba4945dda995225cf3c4017… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2021-09-27 (Mon, 27 Sep 2021) Changed paths: M integration/pom.xml M jcl-over-slf4j/pom.xml M jul-to-slf4j/pom.xml M log4j-over-slf4j/pom.xml M osgi-over-slf4j/pom.xml M pom.xml M slf4j-api/pom.xml M slf4j-ext/pom.xml M slf4j-jdk-platform-logging/pom.xml M slf4j-jdk14/pom.xml M slf4j-log4j12/pom.xml M slf4j-migrator/pom.xml M slf4j-nop/pom.xml M slf4j-simple/pom.xml M slf4j-site/pom.xml Log Message: ----------- fix typo in version name Signed-off-by: Ceki Gulcu <ceki(a)qos.ch>

1 0

NDC Rehabilitation
by Michael Wooten 26 Sep '21

26 Sep '21

I originally opened SLF4J-522 to add a contains() method to the NDC class. I also opened a pull request on Github and had a brief discussion with Ceki on how I was using NDC vs. MDC. My reason for adding the contains() method was I was attempting to implement a library that offered similar functionality to how MDC behaves, specifically with how MDCCloseable can be used to provide a scope for a context. If an existing value already existed in the NDC, I did not want to add it again, and did not want to remove it. For another project, I originally implemented this by directly interfacing with the Log4J ThreadContext, but I would like to implement this using only SLF4J. There has been a trend away from nested diagnostic contexts to mapped ones, which for most cases makes perfect sense. I tend to use both for logging, but for different reasons. Obviously MDC is used to tag information pertinent to a specific instance (like a user ID, order ID, etc.). I tend to think of the mapped context as "what did we get at this logging statement". I typically use the nested context to push identifiers for the different parts of the system, which often correspond to different service layers. I treat the NDC as "how did we get to this logging statement". I often find it useful to know the path through the system to commonly used code, especially if it does not result in an Exception and stack trace. For instance, the NDC [ORDERS_ENDPOINT ORDER_RETURN USER_DAO] would likely be logged in a User DAO, but also indicates it was part of an order return. The NDC [USERS_ENDPOINT REGISTRATION USER_DAO] may be logged from the same statement, but indicates that it was part of a user registration request. I would like to propose several changes for NDC, but would also address several existing tickets in JIRA. 1. Move the NDC class from slf4j-ext to slf4j-api (SLF4J-447). 2. Update NDC to include new methods: a. String peek() - Returns the top context without removing it. b. boolean contains(String) - Returns whether the context stack contains the provided context (SLF4J-522) c. void clear() - Clears the complete context stack (SLF4J-244) 3. Update NDC to use a NDCAdapater similar to how MDC and MDCAdapter works. 4. Include a default NOPNDCAdapter that does nothing. I would also like to additionally propose several other improvements that affect both NDC and MDC. I would like to propose a ScopedLoggingContext class that implements Closeable that would remove potentially multiple MDC and NDC entries for a specific scope. I have implemented this before using a LoggingContext.Builder class that could be configured to add multiple entries to the NDC and MDC contexts. The class included both static and instance methods for updating the context and were meant to be chainable. It also implemented the Supplier interface and would only update the context when get() was called on it. Example: import static ...ScopedLoggingContext.Builder.nestedContext; try (Closeable c = nestedContext("REGISTRATION").mappedContext("ORDER_ID", order.getId()).mappedContext("USER_ID", order.getUserId()).get()) { logger.info("Logged with NDC and MDC values."); } This allows for the same try-with-resources block to add multiple nested or mapped context values and then remove them when the context is auto-closed. In the approach I implemented before, there were special semantics for values already on the NDC or MDC. For our purposes, the NDC did not allow for duplicate contexts (i.e. "[USER ORDERS USER]"). This may not be the case for others, and such a context may be useful. Also, our behavior for MDC was specified as if there was an existing MDC context value, it would be overwritten, but not removed from the context and its original value not restored. In our case this was beneficial since at some points a USER_ID context may be null and then later populated and it was beneficial for the same USER_ID to propagate to future logging statements. I understand that SLF4J-472 addresses the idea of the previous value being restored when the context is closed, and perhaps this is a behavior that could be toggled. In either case, I believe the current implementation of MDCCloseable could potentially be destructive if a nested context updated the same key value. try (MDC.MDCCloseable c1 = MDC.putCloseable("testKey", "value1")) { logger.info("Log message with context testKey=value1"); try (MDC.MDCCloseable c2 = MDC.putCloseable("testKey", "value2")) { logger.info("Log message with context testKey=value2"); } logger.info("Log message without context testKey"); } I would be willing to port my current work to SLF4J and post a PR if there is interest. Is there any interest in reviving and updating the nested diagnostic context? Is there any interest in being able to remove multiple context values (either from MDC or NDC) from a Closeable constructed via a Builder? If so, what should the behaviors be for duplicate context values? Thank you for any consideration, thoughts, or input on this suggestion. -Michael

1 0

[JIRA] Updates for SLF4J-522: Add contains() Method to NDC
by QOS.CH (JIRA) 10 Sep '21

10 Sep '21

SLF4J / SLF4J-522 [Open] Add contains() Method to NDC ============================== 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-522 ============================== 1 comment ------------------------------ Ceki Gülcü on 10/Sep/21 6:41 PM I think NDC should perhaps be rehabilitated. Alternatively, MDC should be enhanced to support a stack stored under a key. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-522: Add contains() Method to NDC
by QOS.CH (JIRA) 09 Sep '21

09 Sep '21

SLF4J / SLF4J-522 [Open] Add contains() Method to NDC ============================== 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-522 ============================== Issue created ------------------------------ Michael Wooten created this issue on 09/Sep/21 5:30 AM Summary: Add contains() Method to NDC Issue Type: Improvement Affects Versions: 2.0.0-alpha4 Assignee: SLF4J developers list Components: slf4j-ext Created: 09/Sep/21 5:30 AM Labels: logging nested Priority: Minor Reporter: Michael Wooten Severity: enhancement Description: I have been working on a library of utilities related to using SLF4J in different environments, and one functionality that I cannot seem to replicate is the ability to test if a value is already in the Nested Diagnostic Context. The only exposed public methods of the org.slf4j.NDC class are push(String) and pop(). There is a size() method that is private. I would like to propose the inclusion of a "boolean contains(String)" method that would return whether the currently configured NDC already includes the provided value. I understand with the current approach this would involve iterating over the MDC similar to how size() does since the NDC is actually emulated with MDC keys. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[qos-ch/slf4j] cf09b2: Class.getPackageName is new to JDK 9
by Ceki Gulcu 08 Sep '21

08 Sep '21

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: cf09b2e34de6216c9aa5b8ba5e7e5db3d5a4da27 https://github.com/qos-ch/slf4j/commit/cf09b2e34de6216c9aa5b8ba5e7e5db3d5a4… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2021-09-08 (Wed, 08 Sep 2021) Changed paths: M slf4j-simple/src/test/java/org/slf4j/simple/multiThreadedExecution/StateCheckingPrintStream.java Log Message: ----------- Class.getPackageName is new to JDK 9 Signed-off-by: Ceki Gulcu <ceki(a)qos.ch>

1 0