- slf4j-dev - mailman3.qos.ch

[qos-ch/slf4j] c025af: Fix the SCM connection URL in pom.xml
by Ceki Gulcu 19 Aug '19

19 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: c025afe5361ed10d80c693e93dd928bf5934b82e https://github.com/qos-ch/slf4j/commit/c025afe5361ed10d80c693e93dd928bf5934… Author: Sebastian Schuberth <sschuberth(a)gmail.com> Date: 2019-08-19 (Mon, 19 Aug 2019) Changed paths: M pom.xml Log Message: ----------- Fix the SCM connection URL in pom.xml The "connection" should be an URL valid for read-only access and has to follow the syntax as described at https://maven.apache.org/pom.html#SCM. Commit: 0d0f187b14c63bd3f61b857351b702ef990ee0f7 https://github.com/qos-ch/slf4j/commit/0d0f187b14c63bd3f61b857351b702ef990e… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-19 (Mon, 19 Aug 2019) Changed paths: M pom.xml Log Message: ----------- Merge pull request #178 from sschuberth/patch-1 Fix the SCM connection URL in pom.xml Compare: https://github.com/qos-ch/slf4j/compare/32532107f5b5...0d0f187b14c6

1 0

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

17 Aug '19

[ https://jira.qos.ch/browse/SLF4J-468?page=com.atlassian.jira.plugin.system.… ] Wessel van Norel commented on SLF4J-468: ---------------------------------------- @ceki I got the updates on this issue, and trying to understand how to get the changes you propose to work. And I'm looking into how to benchmark the changes properly. Since benchmarking is hard. > 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

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

16 Aug '19

[ https://jira.qos.ch/browse/SLF4J-468?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-468: ---------------------------------- [~delgurth] There was a problem sending messages to gmail. Please let me know if you have seem my previous comment. > 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

1.8.0-SNAPSHOT Branch: how can I build this?
by Wessel van Norel 14 Aug '19

14 Aug '19

Hello, @Ceki Gülcü Thanks for approving the 1.7 release commit. I’ve tried to also add it to the 1.8.0-SNAPSHOT branch, but I couldn’t get a build for that branch working quickly. First I had to get a jdk6 and configure the m2 toolchain, but after that it still failed to build on the module-info. After moving that to a java9 directory, as you did in master, it still didn’t work. This because now the 1.6 jdk build was failing on a --release flag given to the javac command. After that I gave up, since I’m not sure if you are still working on 1.8 or that you decided to release a 2.0 to make the breaking character of the changes more clearly. Another thing that I noted during my backporting work was the build has flaky tests, at least on my machine. At least two tests based on the MultithreadedInitializationTest sometimes fail on the last assertTrue in this abstract test. I’ll investigate this further. One remaining question. I moved 2 methods from MessageFormatter to Util. I thought that it was ok to do so because one of them was package private and the other was private. But you moved them back to the MessageFormatter. Is that because it was package private before? So are only private methods ok to change and all other should be considered stable? Kind regards, Wessel

2 1

[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