- slf4j-dev - mailman3.qos.ch

[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

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 28 Dec '21

28 Dec '21

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== 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-371 ============================== 1 comment ------------------------------ JIRA Administrator on 28/Dec/21 7:28 AM Account deactivated upon email request sent by the user. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 28 Dec '21

28 Dec '21

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== 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-371 ============================== 1 comment ------------------------------ Alexander Kiselyov on 28/Dec/21 1:53 AM ??but I am not sure why you are missing/ignoring my point??? I'm equally not sure why are you keep talking to a strawman. The comment I made is quite clear about the fact that I'm not against adding varargs versions to the existing APIs: 'since there's no varargs version of [addArgument|https://www.slf4j.org/api/org/slf4j/spi/LoggingEventBuilder.htm…] or {{addKeyValue}}, *which may actually be useful to have*.', so not against overloading {{log()}} with {{varargs-supporting-Supplier}} version either. But I - just as you are - neither a library owner nor a maintainer/their advisor and, hence, have no influence over making the final decision, so your allegations regarding any deflection, promotion and such are absolutely unfounded and ridiculous. ??pointing at stupid and insignificant errors in my examples?? I never made any comments about the quality of your examples, made any jokes on them or your knowledge of Java, etc., so the only place where you can find any hostility or trolling is your comments, which your last reply to @[~toolforger] illustrates quite clearly. The one and only point of explaining in details why they are not functional was to help you and anyone else who has a similar problem and bumps into this thread to better understand the library API and the programming language they try to use. What I saw in return was false accusations and insults (not only towards me, but other people too), so I don't feel I should answer any of your comments in future. Good luck with whatever you're trying to achieve. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 27 Dec '21

27 Dec '21

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== 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-371 ============================== 1 comment ------------------------------ Eric Kolotyluk on 27/Dec/21 11:21 PM "you can't threaten or pay them to do your bidding" I was not threatening anyone or offering to pay them. For you to say so is a perversion of the narrative and the kind of hostility I was talking about, and you have proved my point about trolling. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-528: Add a LoggerFactory method that infers caller class
by QOS.CH (JIRA) 27 Dec '21

27 Dec '21

SLF4J / SLF4J-528 [Open] Add a LoggerFactory method that infers caller class ============================== 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-528 ============================== 1 comment ------------------------------ Ceki Gülcü on 27/Dec/21 9:50 PM I am aware of the following potential implementations: Implementation 1 {code} // Thread stack trace StackTraceElement[] trace = Thread.currentThread().getStackTrace(); {code} Implementation 2 {code} // use SecurityManager private static final class ClassContextSecurityManager extends SecurityManager { protected Class<?>[] getClassContext() { return super.getClassContext(); } } private static ClassContextSecurityManager getSecurityManager() { try { return new ClassContextSecurityManager(); } catch (java.lang.SecurityException sm) { return null; } } ClassContextSecurityManager securityManager = getSecurityManager(); Class<?>[] trace = securityManager.getClassContext(); {code} Implementation 3 {code} // StackWalker API (new in Java9) StackWalker WALKER = StackWalker.getInstance(); List<StackFrame> frames = WALKER.walk(s -> s.limit(4).collect(Collectors.toList())); {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) 27 Dec '21

27 Dec '21

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 27/Dec/21 9:38 PM Thank you so much for the PR. The {{log()}} method with no arguments adds welcome flexibility to the API. However, I am afraid that users will forget to call {{log()}} after populating the event. That is the reason it was not added in the first place. (I forgot about this reasoning until recently.) So there is this tension between an API which is not as nice but in which mistakes are harder or a nicer API with more potential for errors. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-530: Lambdas should not be evaluated for disabled statements
by QOS.CH (JIRA) 27 Dec '21

27 Dec '21

SLF4J / SLF4J-530 [Resolved] Lambdas should not be evaluated for disabled statements ============================== 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-530 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 27/Dec/21 9:17 PM Resolution: Won't Fix Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 27/Dec/21 9:17 PM Nothing to fix. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 27 Dec '21

27 Dec '21

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== Here's what changed in this issue in the last few minutes. There are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-371 ============================== 2 comments ------------------------------ Eric Kolotyluk on 27/Dec/21 7:25 PM I am using logback behind SLF4J, so I am pretty happy that sflf4jlambda just works, and processes the lambdas without support in the backend. I almost laughed when I realized I was using a facade with a facade, but then, that actually makes sense... ------------------------------ Joachim Durchholz on 27/Dec/21 7:31 PM People have been concentrating on understanding where you come from, so they have a chance to understand where you want to go to. (I have been finding it it a bit hard to follow you. The points you brought forward like there's thought behind them, but I couldn't follow the examples as I didn't see how they related to the points you were trying to make.) Calling them "trolls posing as professionals" isn't going to make them more inclined to follow you, or work on understanding you. In particular since everybody here is a volunteer; you can't threaten or pay them to do your bidding, the best thing you can do is to make them _want_ to help you, and insults are going to make them _not_ want to help you. (This is human nature, and it is independent on whether you have factual basis for insults or not - I don't believe you have, so I the troll is in your own mirror, but that's beside the point.) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 27 Dec '21

27 Dec '21

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== 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-371 ============================== 1 comment ------------------------------ Oleksandr Gavenko on 27/Dec/21 7:05 PM I saw similar approach in https://github.com/logfellow/logstash-logback-encoder for `logger.debug("Lazy logging {}", () -> "called");`. They introduced special type they detect to support structured logging in Logback without waiting for v1.3.0 to become stable: https://github.com/logfellow/logstash-logback-encoder/blob/main/src/main/ja… like `logger.info("log message {}", keyValue("name", "value"));` With lambda & Supplier it is almost the same except we miss the name. `StructuredArguments` is known only to `logstash-logback-encoder` though. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0