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

[JIRA] Updates for SLF4J-556: Exception in Parameterized Message not logged using LocationAwareLogger
by QOS.CH (JIRA) 31 Aug '22

31 Aug '22

SLF4J / SLF4J-556 [Open] Exception in Parameterized Message not logged using LocationAwareLogger ============================== 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-556 ============================== 1 comment ------------------------------ Marian Barton on 31/Aug/22 4:20 PM This appears to be a Log4J bug and not related to SLF4J. My apologies, this bug can be closed. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-556: Exception in Parameterized Message not logged using LocationAwareLogger
by QOS.CH (JIRA) 31 Aug '22

31 Aug '22

SLF4J / SLF4J-556 [Open] Exception in Parameterized Message not logged using LocationAwareLogger ============================== 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-556 ============================== Issue created ------------------------------ Marian Barton created this issue on 31/Aug/22 1:37 PM Summary: Exception in Parameterized Message not logged using LocationAwareLogger Issue Type: Bug Affects Versions: 1.7.36 Assignee: SLF4J developers list Components: Implementations Created: 31/Aug/22 1:37 PM Priority: Major Reporter: Marian Barton Description: +Versions:+ * slf4j-api version 1.7.36 * log4j-slf4j-impl: 2.17.1 +Action:+ Logging a message using LocationAwareLogger.log including an exception as unused last parameter in the argArray. +Result:+ The message is constructed correctly but the exception is being ignored and not logged. +Expected:+ According to the SLF4J FAQ, passing an exception as unused parameter in the last place should result in it being interpreted as Exception and logged as such. +Example:+ {code:java} // Method in wrapping custom logger public void error(final String message, final Object... argArray) { logger.log(null, FQCN, LocationAwareLogger.ERROR_INT, message, argArray, null); } // Call from another class to that method String someString = "insertedString"; LOGGER.log("Test {}", someString, someException); // Result - no exception logged, only message 2022-Aug.-31 12:41:59,829 [https-openssl-nio-443-exec-4] some.Class ERROR Test insertedString // this works though public void error(final String message, final Object... argArray) { logger.error(message, argArray); }{code} The same call works when not using the LocationAwareLogger log method but the standard logger.error(String message, Object... argArray) method. But since I am using a wrapping logger I have to use the LocationAwareLogger interface in order to conserve the location information. +Possible solution:+ I debugged a bit to try and find the issue and I might have found the problem inside the org.apache.logging.slf4j.Log4jLogger.log method: {code:java} @Override public void log(final Marker marker, final String fqcn, final int level, final String message, final Object[] params, Throwable throwable) { final Level log4jLevel = getLevel(level); final org.apache.logging.log4j.Marker log4jMarker = getMarker(marker); if (!logger.isEnabled(log4jLevel, log4jMarker, message, params)) { return; } final Message msg; if (CONVERTER != null && eventLogger && marker != null && marker.contains(EVENT_MARKER)) { msg = CONVERTER.convertEvent(message, params, throwable); } else if (params == null) { msg = new SimpleMessage(message); } else { msg = new ParameterizedMessage(message, params, throwable); if (throwable != null) { throwable = msg.getThrowable(); } } logger.logMessage(fqcn, log4jLevel, log4jMarker, msg, throwable); } {code} The problem here specifically being this part: {code:java} } else { msg = new ParameterizedMessage(message, params, throwable); if (throwable != null) { throwable = msg.getThrowable(); } } {code} SLF4J successfully detects this as and creates a ParameterizedMessage. This instance also correctly found the Throwable from the parameters and set it to its throwable property. Now I think the bug here is that the if condition is inverted. As I have no Throwable explicitly passed to this method (because it is passed via the params), it is currently null. In this case SLF4J should check if a Throwable is set and if not try to get it from the ParameterizedMessage, because there it was successfully detected inside the constructor. The correct implementation would therefore be: {code:java} } else { msg = new ParameterizedMessage(message, params, throwable); if (throwable == null) { throwable = msg.getThrowable(); } } {code} If the throwable is not set here, it remains inside the ParameterizedMessage and is ignored by Log4J, as Log4J appears to only respect the explicit Throwable parameter. Any questions, feedback and help are/is appreciated. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Stack-valued MDC in SLF4J 2.0
by Piotr P. Karwasz 28 Aug '22

28 Aug '22

Hi all, I am implementing the new MDC methods in the Log4j2 bridge and I have some questions on the behavior of the `popByKey/pushByKey`, that I couldn't resolve reading the Javadoc[1]. Regarding 'pushByKey(key, value)': * can the key be null? The `BasicMDCAdapter` implementation does not allow it/ignores it, but this could be a good way to reference Reload4j/Log4j's NDC, * can the value be null? The current implementation does not allow them and the Deque Javadoc discourages adding null to a deque, but SLF4J Javadoc is not precise in this matter (e.g. it does not contain '@throws NullPointerException if the value is null'), * is the Deque limited in size? Regarding `popByKey(key, value)': * the Javadoc suggests that popping an empty stack returns null, while the `BasicMDCAdapter` implementation delegates to `Deque#pop()` which throws a `NoSuchElementException`. Is it a bug or an undocumented feature? By comparison popping the NDC in Log4j/Reload4j returns null if the stack is empty, while Log4j2 throws an exception. Piotr [1] https://www.slf4j.org/api/org/slf4j/MDC.html

1 0

[JIRA] Updates for SLF4J-387: Implement putAll and putAllClosable
by QOS.CH (JIRA) 28 Aug '22

28 Aug '22

SLF4J / SLF4J-387 [In Progress] Implement putAll and putAllClosable ============================== 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-387 ============================== 1 comment ------------------------------ Ceki Gülcü on 28/Aug/22 6:30 PM [~pkarwasz] Chaining {{put}} methods is a pretty nifty idea. Thanks! Regarding the second suggestion: restoring the previous value is different than a stack of arbitrary depth. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-387: Implement putAll and putAllClosable
by QOS.CH (JIRA) 28 Aug '22

28 Aug '22

SLF4J / SLF4J-387 [In Progress] Implement putAll and putAllClosable ============================== 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-387 ============================== 1 comment ------------------------------ Piotr P. Karwasz on 28/Aug/22 9:04 AM [~ceki], Why not extend the {{MDCCloseable}} with a {{put(String key, String value)}} method? Then it would be possible to write: {code:java} try (Closeable temp = MDC.putCloseable("key1", "value1").put("key2", "value2")) { // Do stuff } {code} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-387: Implement putAll and putAllClosable
by QOS.CH (JIRA) 27 Aug '22

27 Aug '22

SLF4J / SLF4J-387 [In Progress] Implement putAll and putAllClosable ============================== 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-387 ============================== 1 comment ------------------------------ Ceki Gülcü on 27/Aug/22 10:57 PM [~Raniz] The values in the list represent MDC keys that need to be reset to null. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-387: Implement putAll and putAllClosable
by QOS.CH (JIRA) 27 Aug '22

27 Aug '22

SLF4J / SLF4J-387 [In Progress] Implement putAll and putAllClosable ============================== 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-387 ============================== 1 comment ------------------------------ Daniel Raniz Raneland on 27/Aug/22 9:44 PM I don't understand how that would even work. You put keys and values into the MDC. What would the values in the list represent? I definitely knew both the keys and values when I felt the need for this function ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-387: Implement putAll and putAllClosable
by QOS.CH (JIRA) 26 Aug '22

26 Aug '22

SLF4J / SLF4J-387 [In Progress] Implement putAll and putAllClosable ============================== 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-387 ============================== 1 comment ------------------------------ Ceki Gülcü on 26/Aug/22 6:23 PM Would you be satisfied with {{MDC.putAllCloseable(List<String>)}} ? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-124: Add ability to log at a dynamic level
by QOS.CH (JIRA) 23 Aug '22

23 Aug '22

SLF4J / SLF4J-124 [Resolved] Add ability to log at a dynamic level ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-124 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 23/Aug/22 10:35 PM Resolution: Fixed Status: Resolved (was: In Progress) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-555: Binders are deprecated in SLF4J 2
by QOS.CH (JIRA) 23 Aug '22

23 Aug '22

SLF4J / SLF4J-555 [Resolved] Binders are deprecated in SLF4J 2 ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-555 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 23/Aug/22 10:43 PM Resolution: Fixed Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0