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

[JIRA] (SLF4J-470) slf4j upgrade from 1.5.6 to 1.7.28 is causing default logging level to DEBUG
by QOS.CH (JIRA) 29 Aug '19

29 Aug '19

[ https://jira.qos.ch/browse/SLF4J-470?page=com.atlassian.jira.plugin.system.… ] Shankar U H commented on SLF4J-470: ----------------------------------- We were using logback-classic 1.1.3 with slf4j 1.5.6 then upgraded logback-classic to 1.2.3 and slf4j to 1.7.8 > slf4j upgrade from 1.5.6 to 1.7.28 is causing default logging level to DEBUG > ---------------------------------------------------------------------------- > > Key: SLF4J-470 > URL: https://jira.qos.ch/browse/SLF4J-470 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.28 > Reporter: Shankar U H > Assignee: SLF4J developers list > > Hi team, > Recently we had to upgrade logback-classic and as its dependency we upgraded slf4j-api from 1.5.6 to 1.7.28. > After this upgrade,we are seeing DEBUG logs being set by default. > Reverting back to 1.5.6 does not have this problem. > No configuration changes were done ,just the jar was replaced with latest jar. > > Please let us know how we can have same log behaviour as in slf4j-api 1.5.6 with slf4j-1.7.28 without any configuration changes. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-470) slf4j upgrade from 1.5.6 to 1.7.28 is causing default logging level to DEBUG
by QOS.CH (JIRA) 28 Aug '19

28 Aug '19

[ https://jira.qos.ch/browse/SLF4J-470?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-470: ---------------------------------- This seems rather strange. Which version of logback are you using? > slf4j upgrade from 1.5.6 to 1.7.28 is causing default logging level to DEBUG > ---------------------------------------------------------------------------- > > Key: SLF4J-470 > URL: https://jira.qos.ch/browse/SLF4J-470 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.28 > Reporter: Shankar U H > Assignee: SLF4J developers list > > Hi team, > Recently we had to upgrade logback-classic and as its dependency we upgraded slf4j-api from 1.5.6 to 1.7.28. > After this upgrade,we are seeing DEBUG logs being set by default. > Reverting back to 1.5.6 does not have this problem. > No configuration changes were done ,just the jar was replaced with latest jar. > > Please let us know how we can have same log behaviour as in slf4j-api 1.5.6 with slf4j-1.7.28 without any configuration changes. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-470) slf4j upgrade from 1.5.6 to 1.7.28 is causing default logging level to DEBUG
by QOS.CH (JIRA) 28 Aug '19

28 Aug '19

Shankar U H created SLF4J-470: --------------------------------- Summary: slf4j upgrade from 1.5.6 to 1.7.28 is causing default logging level to DEBUG Key: SLF4J-470 URL: https://jira.qos.ch/browse/SLF4J-470 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.7.28 Environment: Hi team, Recently we had to upgrade logback-classic and as its dependency we upgraded slf4j-api from 1.5.6 to 1.7.28. After this upgrade,we are seeing DEBUG logs being set by default. Reverting back to 1.5.6 does not have this problem. No configuration changes were done ,just the jar was replaced with latest jar. Please let us know how we can have same log behaviour as in slf4j-api 1.5.6 with slf4j-1.7.28 without any configuration changes. Reporter: Shankar U H Assignee: SLF4J developers list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 13 is now in the Release Candidate Phase & JDK 14 build 11 is available.
by Rory O'Donnell 24 Aug '19

24 Aug '19

Hi Ceki, *JDK 13 is now in the Release Candidate Phase * Per the JDK 13 schedule [1], we are now in the Release Candidate phase. The stabilization repository, jdk/jdk13, is open for P1 bug fixes per the JDK Release Process (JEP 3) [2]. All changes require approval via the Fix-Request Process [3]. For more details, see Mark Reinhold's email to jdk-dev mailing list [4] * Milestone Schedule: o GAC - Aug 22, 2019 o GAR - Sept 5, 2019 o GA - Sept 17, 2019 **OpenJDK 14 *EA build 11 is now available at **http://jdk.java.net/14** * * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Release Notes o http://jdk.java.net/14/release-notes * JEPs targeted to JDK 14 o JEP 352 <http://openjdk.java.net/jeps/352> - Non-Volatile Mapped Byte Buffers * Significant changes since the last availability email: o Build 10 + 8226374: Restrict TLS signature schemes and named groups + 8227439: Turn off AOT by default o Build 11 + 8224974: Implement JEP 352 * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B10%22%3A%3…> *jpackage EA - **Build 1 (2019/8/20) * * This is an early access build of JEP 343: Packaging Tool <https://openjdk.java.net/jeps/343>, aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Build 1 (2019/8/20) is now available http://jdk.java.net/jpackage/ * Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> Regards, Rory [1] https://openjdk.java.net/projects/jdk/13/#Schedule [2] https://openjdk.java.net/jeps/3 [3] https://openjdk.java.net/jeps/3#Fix-Request-Process [4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-469) Potential memory leaks if there is no underlying implementation
by QOS.CH (JIRA) 22 Aug '19

22 Aug '19

yu created SLF4J-469: ------------------------ Summary: Potential memory leaks if there is no underlying implementation Key: SLF4J-469 URL: https://jira.qos.ch/browse/SLF4J-469 Project: SLF4J Issue Type: Bug Affects Versions: 1.7.26 Environment: java 8 slf4j 1.7.26 Reporter: yu Assignee: SLF4J developers list Priority: Critical *If I don't have 'logback' 'log4j'...... Implementation class* The problem lies in the method *public static ILoggerFactory getILoggerFactory()* first Thread1: {code:java} if (INITIALIZATION_STATE == UNINITIALIZED) { init..... } {code} secode Thread2: {code:java} case ONGOING_INITIALIZATION: return SUBST_FACTORY;{code} obtained "SUBST_FACTORY"， and obtained "SubstituteLogger" third: Thread1: {code:java} //init failed cache "NoClassDefFoundError" INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION; {code} *The SubstituteLogger obtained by Thread2 will always output the log to the queue until the memory overflows.* {code:java} // code placeholder synchronized public Logger getLogger(String name) { SubstituteLogger logger = loggers.get(name); if (logger == null) { logger = new SubstituteLogger(name, eventQueue, postInitialization); loggers.put(name, logger); } return logger; } public void info(String msg) { delegate().info(msg); } Logger delegate() { if(_delegate != null) { //_delegate== null forever return _delegate; } if(createdPostInitialization) { createdPostInitialization == false forever return NOPLogger.NOP_LOGGER; } else { return getEventRecordingLogger(); } } {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 6f217b: minor edits
by Ceki Gulcu 19 Aug '19

19 Aug '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 6f217bbf630596b27c4f8dd59ffba1985b2367b7 https://github.com/qos-ch/slf4j/commit/6f217bbf630596b27c4f8dd59ffba1985b23… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-08-19 (Mon, 19 Aug 2019) Changed paths: M slf4j-site/src/site/pages/manual.html Log Message: ----------- minor edits

1 0

[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