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

[qos-ch/slf4j] a7562c: SLF4J-466: backport changes to 1.7
by Ceki Gulcu 14 Aug '19

14 Aug '19

Branch: refs/heads/1.7-maintenance Home: https://github.com/qos-ch/slf4j Commit: a7562cb4b928c225192405b4d849246db60107d4 https://github.com/qos-ch/slf4j/commit/a7562cb4b928c225192405b4d849246db601… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-14 (Wed, 14 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 A slf4j-api/src/test/java/org/slf4j/event/EventRecodingLoggerTest.java Log Message: ----------- SLF4J-466: backport changes to 1.7 SLF4J-466: backport changes to 1.7 SLF4J-466: corrected whitespace SLF4J-466: corrected whitespace Commit: 125e7cca190c48fedcb92f377fd7361661f7537c https://github.com/qos-ch/slf4j/commit/125e7cca190c48fedcb92f377fd7361661f7… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-14 (Wed, 14 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 A slf4j-api/src/test/java/org/slf4j/event/EventRecodingLoggerTest.java Log Message: ----------- Merge pull request #219 from delgurth/1.7-maintenance-with-slf4j-466 SLF4J-466: backport changes to 1.7 Compare: https://github.com/qos-ch/slf4j/compare/9752c892fdf4...125e7cca190c

1 0

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

13 Aug '19

[ https://jira.qos.ch/browse/SLF4J-468?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-468: ---------------------------------- I updated my comment above. > 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] e757c4: Fix the build and a typo
by Ceki Gulcu 13 Aug '19

13 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: e757c41a57f7d57f5889144ad09d77a8b57f92ac https://github.com/qos-ch/slf4j/commit/e757c41a57f7d57f5889144ad09d77a8b57f… Author: Wessel van Norel <wessel.van.norel(a)delgurth.com> Date: 2019-08-14 (Wed, 14 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java Log Message: ----------- Fix the build and a typo Commit: 32532107f5b520fcaeb1220cac91dc72f36915d6 https://github.com/qos-ch/slf4j/commit/32532107f5b520fcaeb1220cac91dc72f369… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-14 (Wed, 14 Aug 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java Log Message: ----------- Merge pull request #218 from delgurth/SLF4J-466-Fix-build Fix the build and a typo Compare: https://github.com/qos-ch/slf4j/compare/78c10ee651d0...32532107f5b5

1 0

MessageFormatter: small performance improvement for 1 and 2 object parameter cases?
by Wessel van Norel 13 Aug '19

13 Aug '19

Hi all, When I was looking at the issue with the Throwable parameter in the EventRecordingLogger (SLF4J-466[1]) I also stumbled upon an issue within the MessageFormatter. I opened SLF4J-468[2] for that. Ceki asked me to explain this issue to the list, since a change in this class is not something we should do lightly. There are two cases. Case 1: In case you pass one object to the format method[3] it will put that object in an Object[] and then the next method will call yet another method to see if that Object[]'s last element is a Throwable. And if so it will create a new Object[] containing 0 elements and it will try to do the formatting logic, even though there is nothing to format. My proposed changes: 2.0.0: - Directly call the actual message formatting function with an Object[1] argArray and null throwable.[4] The downside of this change is that if the one object format message is called with a Throwable you no longer get 0 arguments and a Stacktrace, you get 1 argument and no Stacktrace. But why would you call the format method if you already know there is nothing to format? 1.7.x: - Add an instanceof check to the object argument - Call the actual formatting function with either null as argArray or null as throwable and the actual argument on the other. - Extend the argArray == null check with || argArray.length == 0 and change the return to return new FormattingTuple(messagePattern, null, throwable); I think this last change should also be in the 2.0.0 branch, but it's not strictly required for this issue. But now the Throwable might get lost in case someone calls the actual formatting function with an empty argument array. Case 2: In case you pass two objects to the format method[5] it will put both objects in an Object[] and then the next method will call yet another method to see if the last Object in this Object[] is a Throwable. And if so it will create a new Object[] containing only the first element, which it copies from the original Object[]. And then it will do the normal formatting logic. My proposed changes, for both branches: - Add an instanceof check to the second object argument - Call the actual formatting function with either an Object[2] argArray and null throwable, or an Object[1] argArray and the throwable. Of course, it would even be nicer to not have to do the get last parameter and check if it's a Throwable and if so do some other magic then in the other case. But as a user of the logging framework the current way of working is very convenient and logical. So I guess we cannot change that in the current API but only in the new fluent API? I hope I explained the issue clearly. Kind regards, Wessel [1] https://jira.qos.ch/browse/SLF4J-466 [2] https://jira.qos.ch/browse/SLF4J-468 [3] https://www.slf4j.org/apidocs/org/slf4j/helpers/MessageFormatter.html#forma… [4] https://www.slf4j.org/apidocs/org/slf4j/helpers/MessageFormatter.html#array… [5] https://www.slf4j.org/apidocs/org/slf4j/helpers/MessageFormatter.html#forma…

2 1

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

13 Aug '19

[ https://jira.qos.ch/browse/SLF4J-466?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-466. ------------------------------ Resolution: Fixed Fixed in [commit 4ed244| https://github.com/qos-ch/slf4j/commit/4ed24489fa807d] in master. Not fixed in 1.7-maintenance. > 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

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

13 Aug '19

[ https://jira.qos.ch/browse/SLF4J-466?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-466: ---------------------------------- Yes, please that would be quite nice. > 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

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

13 Aug '19

[ https://jira.qos.ch/browse/SLF4J-466?page=com.atlassian.jira.plugin.system.… ] Wessel van Norel commented on SLF4J-466: ---------------------------------------- Should I backport the changes to 1.7.x? > 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

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

13 Aug '19

[ https://jira.qos.ch/browse/SLF4J-468?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-468: ---------------------------------- With hindsight, I think {MessageFormatter}} does too much. It formats the message with arguments and also normalizes the argArray and the throwable via the {{FormattingTuple}}. I think the code would be cleaner if {{MessageFormatter}} did only formatting and the normalization of the arguments was done somewhere else, for example by the printing methods (debug, info, etc) as done in {{EventRecordingLogger}}. I suggest creating a new class, say {{MessageFormatter2}} (name to be discussed) with methods that do not handle the throwable nor return a {{FormattingTuple}}. The actual formatting code could have variants taking 1, 2 or more arguments without the necessity to create intermediary {{Object[]}}. > 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] 78c10e: refactored EventRecodingLogger and EventRecodingLo...
by Ceki Gulcu 13 Aug '19

13 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 78c10ee651d0c8317971982cbcfdf963aabc8285 https://github.com/qos-ch/slf4j/commit/78c10ee651d0c8317971982cbcfdf963aabc… 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/test/java/org/slf4j/event/EventRecodingLoggerTest.java Log Message: ----------- refactored EventRecodingLogger and EventRecodingLoggerTest

1 0

[qos-ch/slf4j] 178e83: move methods from Util back to MessageFormatter
by Ceki Gulcu 13 Aug '19

13 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 178e836f714c3024c6317fb1b09760d4b5c9e2fe https://github.com/qos-ch/slf4j/commit/178e836f714c3024c6317fb1b09760d4b5c9… 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 Log Message: ----------- move methods from Util back to MessageFormatter

1 0