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

[qos-ch/slf4j] fe440c: SLF4j-466: Add test for all happy flow cases
by Ceki Gulcu 13 Aug '19

13 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: fe440ce9cdf1637dfd8aa9998114c627ff7c1078 https://github.com/qos-ch/slf4j/commit/fe440ce9cdf1637dfd8aa9998114c627ff7c… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: A slf4j-api/src/test/java/org/slf4j/event/EventRecodingLoggerTest.java Log Message: ----------- SLF4j-466: Add test for all happy flow cases Commit: b99ad9f80f937a91209accd9561332bb9fa30312 https://github.com/qos-ch/slf4j/commit/b99ad9f80f937a91209accd9561332bb9fa3… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java Log Message: ----------- SLF4j-466: add missing marker in one of the warn methods Commit: a09d78831003bc155ca9ea5374d24dde24dd2976 https://github.com/qos-ch/slf4j/commit/a09d78831003bc155ca9ea5374d24dde24dd… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/helpers/MessageFormatter.java M slf4j-api/src/main/java/org/slf4j/helpers/Util.java Log Message: ----------- SLF4j-466: Move two methods from MessageFormatter to Util so they can be used by the EventRecordingLogger as well Commit: 9df5d4fe915b887ff610a50fca30fe1064d63c66 https://github.com/qos-ch/slf4j/commit/9df5d4fe915b887ff610a50fca30fe1064d6… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java Log Message: ----------- SLF4j-466: put the throwable at the right place of the SubstituteLoggingEvent, introduced two more recordEvent methods for the two object argument log statements Commit: 7c3d35596f93142cd75a7c1d00c677c9c3051d0b https://github.com/qos-ch/slf4j/commit/7c3d35596f93142cd75a7c1d00c677c9c305… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/helpers/Util.java Log Message: ----------- SLF4j-466: only call arraycopy if we have elements to copy Commit: 587ec03af793126782efb6f8196b2487e524801f https://github.com/qos-ch/slf4j/commit/587ec03af793126782efb6f8196b2487e524… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/test/java/org/slf4j/event/EventRecodingLoggerTest.java Log Message: ----------- SLF4j-466: added missing newline at end of file Commit: a98bd22216fabe015635445be7ba9e77caabee72 https://github.com/qos-ch/slf4j/commit/a98bd22216fabe015635445be7ba9e77caab… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/helpers/Util.java Log Message: ----------- SLF4j-466: fixed typo in javadoc Commit: b0b57b9f9b261158d4c888f6527018c5f80eed8b https://github.com/qos-ch/slf4j/commit/b0b57b9f9b261158d4c888f6527018c5f80e… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java Log Message: ----------- SLF4j-466: if was missing a space Commit: 4ed24489fa807d9150f4cd9b46b207a4f4373324 https://github.com/qos-ch/slf4j/commit/4ed24489fa807d9150f4cd9b46b207a4f437… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-13 (Tue, 13 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java M slf4j-api/src/main/java/org/slf4j/helpers/MessageFormatter.java M slf4j-api/src/main/java/org/slf4j/helpers/Util.java A slf4j-api/src/test/java/org/slf4j/event/EventRecodingLoggerTest.java Log Message: ----------- Merge pull request #215 from delgurth/SLF4J-466 Fixes SLF4J-466 Compare: https://github.com/qos-ch/slf4j/compare/8a5c449bd824...4ed24489fa80

1 0

[JIRA] (SLF4J-468) MessageFormatter codepath improvements in case of one and two Object parameters
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

Wessel van Norel created SLF4J-468: -------------------------------------- Summary: MessageFormatter codepath improvements in case of one and two Object parameters Key: SLF4J-468 URL: https://jira.qos.ch/browse/SLF4J-468 Project: SLF4J Issue Type: Improvement Affects Versions: 1.7.x Reporter: Wessel van Norel Assignee: SLF4J developers list Priority: Minor The pseudo path the code follows in case of one argument is: org.slf4j.helpers.MessageFormatter#format(java.lang.String, java.lang.Object) create Object Array with size one and put the parameter in it get length of array check if Element[length -1] of this Array is a Throwable if throwable create empty object array create new Stringbuffer to contain message append message to Stringbuffer return Stringbuffer else normal codeflow to format the message with argument fi The flow around a Throwable is suboptimal, which is logical since you should not be calling this with just a Throwable. But by adding a instanceof call to this method and then calling org.slf4j.helpers.MessageFormatter#arrayFormat(java.lang.String, java.lang.Object[], java.lang.Throwable) directy with the proper parameters safes the get & check in the array and in case of Throwable the new array and unneeded stringbuffer creation. Skipping the instanceof call might result in undesired behaviour in case a logger implementation is calling this formatter even though it has no need for it. I would suggest that for 2.0.0 the instanceof check is not added, but for 1.7.x it contains it, so the library behaves as before the change, but a little bit faster. The pseudo code path for the 2 argument version is: org.slf4j.helpers.MessageFormatter#format(java.lang.String, java.lang.Object, java.lang.Object) create Object Array with size two and put both parameters in it get length of array check if Element[length -1] of this Array is a Throwable if Throwable create object array with size 1 and copy first element of the size two array into it normal codeflow to format the message with argument else normal codeflow to format the message with arguments fi With an instanceof and then directly calling org.slf4j.helpers.MessageFormatter#arrayFormat(java.lang.String, java.lang.Object[], java.lang.Throwable) safes some processing in both cases. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] b266bb: Change the java indent from 2 to 4.
by Ceki Gulcu 12 Aug '19

12 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: b266bb29374e37b63ae106f3177941df10b9aa6f https://github.com/qos-ch/slf4j/commit/b266bb29374e37b63ae106f3177941df10b9… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M .idea/codeStyleSettings.xml Log Message: ----------- Change the java indent from 2 to 4. Commit: 8a5c449bd82427113581f8c6c381b1d7a05274f1 https://github.com/qos-ch/slf4j/commit/8a5c449bd82427113581f8c6c381b1d7a052… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-12 (Mon, 12 Aug 2019) Changed paths: M .idea/codeStyleSettings.xml Log Message: ----------- Merge pull request #217 from delgurth/fix-intellij-java-indent Change the java indent from 2 to 4. Compare: https://github.com/qos-ch/slf4j/compare/206449b67433...8a5c449bd824

1 0

[JIRA] (SLF4J-466) EventRecordingLogger does not properly support the Throwable as last parameter
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

[ https://jira.qos.ch/browse/SLF4J-466?page=com.atlassian.jira.plugin.system.… ] Wessel van Norel commented on SLF4J-466: ---------------------------------------- I just created a pull request for this issue. By adding the test I also found another bug, one of the warn methods was missing the marker argument. As you can see in the commit: https://github.com/delgurth/slf4j/commit/b99ad9f80f937a91209accd9561332bb9f… The pull request: https://github.com/qos-ch/slf4j/pull/215 > EventRecordingLogger does not properly support the Throwable as last parameter > ------------------------------------------------------------------------------ > > Key: SLF4J-466 > URL: https://jira.qos.ch/browse/SLF4J-466 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.7.x > Reporter: Wessel van Norel > Assignee: Ceki Gülcü > Priority: Minor > Fix For: 2.0.0-alpha1 > > > [As per FAQ if the last parameter is a Throwable it should be accepted as the thing you want the stacktrace off.|https://www.slf4j.org/faq.html#paramException] > In the current EventRecordingLogger implementation, in case you pass two or more objects to the logger the (optional) last Throwable is seen as just an argument and not the actual Throwable. > > This issue also affects 1.8.x and 2.0.x. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Missing Trowables in EventRecordingLogger
by Wessel van Norel 12 Aug '19

12 Aug '19

Hi, I was recently doing a code review for a coworker and saw that he was concatenating strings and not using the varargs method of building the log message. I asked him why he was doing that and he explained it was because he also had a Throwable that he wanted to be passed as argument to see the stacktrace. He was not aware of the change in SLF4J 1.6.0 which allows us to pass a Throwable as last argument to the varargs. "Unfortunately", when I was showing him implementations of this, I encountered the slf4j EventRecordingLogger and this implementation of the slf4j logger does not comply with this "new" behaviour. However I'm not sure if this is intentional. Assuming it's not intentional, I've created a fork and I've made the required changes. But before I spend "days" on this while it's intentional I thought: let's write a quick email about this and ask for guidance. I also saw that in the case of 2 Object arguments, the MessageFormatter seems to be suboptimal and is creating more objects then strictly required. For the 1 Object argument case it it's also doing too much, certainly in case someone calls it with a Throwable. I've now added a runtime check to it. Since overloading it with a Throwable version will change the way the method behaves in case the caller does not know if it's being given a Throwable or an Object. It would be very illogical to call this method with a Throwable, with the 1.6 way of dealing with Throwables, since what do you want to format then? But with the runtime check people won't loose their stacktraces, and otherwise in case the MessageFormatter is being used in a wrong way people will see their stacktraces being converted into one line because of a (minor? it's one instanceof call too many per call to the one Object logger variant) performance optimization. I've not yet created the test cases for the EventRecordingLogger, I'll do that in case it's indeed unintentional that it's loosing the Throwables. I've added two tests for the changes I made to the MessageFormatter. While I was at it I also applied some improvements IntelliJ suggested. You can see my changes on my fork: https://github.com/qos-ch/slf4j/compare/master...delgurth:eventrecordinglog… I hope you are able to review my changes and shed your light on it. Kind regards, Wessel van Norel

2 3

[JIRA] (SLF4J-467) Download link is broken
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

[ https://jira.qos.ch/browse/SLF4J-467?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-467. ------------------------------ Resolution: Fixed fixed > Download link is broken > ----------------------- > > Key: SLF4J-467 > URL: https://jira.qos.ch/browse/SLF4J-467 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 2.0.0-alpha0 > Reporter: Gili > Assignee: Ceki Gülcü > > [https://www.slf4j.org/download.html] references 2.0.0-alpha1 but the download links are broken and in fact Maven only contains alpha 0. > Please update these links to alpha 0. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Fwd: investigation on the diffusion of innovation along with java releases
by Fernando Petrulio 12 Aug '19

12 Aug '19

Dear Developers, we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8’s lambdas. During the course of our investigation, we manually inspected SLF4J’s source code and documentation to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings. Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization. Our analysis showed that though SLF4J 2.0 did not explicitly introduce support for functional interfaces (e.g. by using the @FunctionalInterface annotation). We noticed that the API does provide compatibility with Java 8+ features, including lambda expressions (since the API’s build platform is now on JDK 1.8). We would like to better understand as to why no major change was necessitated to facilitate the usage of lambda expressions with the API. In most cases, developers choose to move to new releases to satisfy particular dependency requirements, to take advantage of new Java features (like streams and functional interfaces in the case of Java 8), or just to standardize their implementation to align the API with the Java JDK API. Can you provide us with more information about this? How did you and your team tackle the choice to change the version of Java supported? Which factors did you take into account when doing this? Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with? Why were no explicit changes made to the interface to support lambda expressions? Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported? We thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know! Kind Regards, Fernando Petrulio. -- Fernando Petrulio Ph.D. Student - University of Zurich UZH Department of Informatics fpetrulio(a)ifi.uzh.ch

3 5

[JIRA] (SLF4J-467) Download link is broken
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

Gili created SLF4J-467: -------------------------- Summary: Download link is broken Key: SLF4J-467 URL: https://jira.qos.ch/browse/SLF4J-467 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0.0-alpha0 Reporter: Gili Assignee: SLF4J developers list [https://www.slf4j.org/download.html] references 2.0.0-alpha1 but the download links are broken and in fact Maven only contains alpha 0. Please update these links to alpha 0. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-371: ---------------------------------- [~deanhiller] Please create a bug report regarding incorrect caller information. A test case would be most welcome. > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: Ceki Gülcü > Fix For: 2.0.0-alpha1 > > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-466) EventRecordingLogger does not properly support the Throwable as last parameter
by QOS.CH (JIRA) 12 Aug '19

12 Aug '19

Wessel van Norel created SLF4J-466: -------------------------------------- Summary: EventRecordingLogger does not properly support the Throwable as last parameter Key: SLF4J-466 URL: https://jira.qos.ch/browse/SLF4J-466 Project: SLF4J Issue Type: Bug Components: Implementations Affects Versions: 1.7.x, 1.6.x Reporter: Wessel van Norel Assignee: SLF4J developers list Priority: Minor [As per FAQ if the last parameter is a Throwable it should be accepted as the thing you want the stacktrace off.|https://www.slf4j.org/faq.html#paramException] In the current EventRecordingLogger implementation, in case you pass two or more objects to the logger the (optional) last Throwable is seen as just an argument and not the actual Throwable. This issue also affects 1.8.x and 2.0.x. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0