December 2021 - slf4j-dev - mailman3.qos.ch

[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

[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 6:38 PM > Just to make things clear: the last listing won't work either Fair enough {code:java} Supplier task = () -> {System.out.println("task evaluated"); return "called";}; {code} but I am not sure why you are missing/ignoring my point? {code:java} logger1.atDebug().addArgument(() -> "called").log("Lazy logging {}"); {code} is just uglier than {code:java} logger2.debug("Lazy logging {}", () -> "called"); {code} I can only conclude that you are using deliberately pointing at stupid and insignificant errors in my examples as some ad hominem argument to score points, to deflect, to minimize, to advocate for Fluent, to promote political opinion instead of technical opinion? What is your point? _I joined this conversation to simply advocate for adding 'nice' lambda support in SLF4J, nothing more. Eventually I learned that SLF4J 2.0 has some minimal support, but at the cost have 'having' to learn/use Fluent. Eventually I learned there is a facade for the SLF4J facade that does exactly what I was advocating for in the the first place._ I do not understand why my comments have been met with so much hostility and perversion by trolls posing as professionals. ============================== 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 ------------------------------ Alexander Kiselyov on 27/Dec/21 4:57 PM Just to make things clear: the last listing won't work either - it'll just print the standard {{Object.toString()}} return value ({{ getClass().getName() + '@' + Integer.toHexString(hashCode())}}) :) Reason is, {{Callable}} interface is not the same as {{Supplier}} (though signature is quite similar), and, hence, your resulting anonymous class does not implement it, so {{addArgument(Object)}} will be invoked instead of {{addArgument(Supplier<?>)}}. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0