- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-472) Should MDCClosable put the old value back into the MDC?
by QOS.CH (JIRA) 04 Sep '19

04 Sep '19

Stephen created SLF4J-472: ----------------------------- Summary: Should MDCClosable put the old value back into the MDC? Key: SLF4J-472 URL: https://jira.qos.ch/browse/SLF4J-472 Project: SLF4J Issue Type: Improvement Reporter: Stephen Assignee: SLF4J developers list Priority: Minor I'm not actually sure about this myself. Currently when you close the MDCClosable it will remove the value from the MDC. The close method doesn't put things back to the way they were. The put method called when MDCClosable is created returns void so this isn't a trivial thing to implement. I imagine that different logging providers might not return the old value like the put method on the map. Should something like this be implemented? -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-471) CharSequence and varargs
by QOS.CH (JIRA) 02 Sep '19

02 Sep '19

[ https://jira.qos.ch/browse/SLF4J-471?page=com.atlassian.jira.plugin.system.… ] Foo Far commented on SLF4J-471: ------------------------------- [The CharSequence interface|https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequence.…] is implemented by both String (which cannot be easily preallocated) and nio CharBuffer (which can). Java String cannot be easily preallocated because it is strictly immutable. The CharSequence could be implemented by a class with only private mutability, that allocates at time 1, and initializes via a factory method at time 2. > CharSequence and varargs > ------------------------ > > Key: SLF4J-471 > URL: https://jira.qos.ch/browse/SLF4J-471 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Foo Far > Assignee: SLF4J developers list > > Could sl4fj provide an interface that enables avoiding all object allocation? > This is important for low latency applications, which only allocate objects at startup, in order to prevent even minor collection pauses. > The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they initially work with allocations. > For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-471) CharSequence and varargs
by QOS.CH (JIRA) 02 Sep '19

02 Sep '19

[ https://jira.qos.ch/browse/SLF4J-471?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-471: ---------------------------------- As you are aware, SFL4J 2.0 introduced a fluent API. Since the API is still in alpha phase, we could replace the String message/format parameter with a CharSequence with no consequences. However, can you please explain why CharSequence is any better than String with regards to pre-allocation? Any references? > CharSequence and varargs > ------------------------ > > Key: SLF4J-471 > URL: https://jira.qos.ch/browse/SLF4J-471 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Foo Far > Assignee: SLF4J developers list > > Could sl4fj provide an interface that enables avoiding all object allocation? > This is important for low latency applications, which only allocate objects at startup, in order to prevent even minor collection pauses. > The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they initially work with allocations. > For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-471) CharSequence and varargs
by QOS.CH (JIRA) 01 Sep '19

01 Sep '19

Foo Far created SLF4J-471: ----------------------------- Summary: CharSequence and varargs Key: SLF4J-471 URL: https://jira.qos.ch/browse/SLF4J-471 Project: SLF4J Issue Type: Bug Components: Core API Environment: Could sl4fj provide an interface that enables avoiding all object allocation? This is important for low latency applications, which only allocation objects at startup, in order to prevent even minor collection pauses. The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they work with allocations. For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface. Reporter: Foo Far Assignee: SLF4J developers list -- 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) 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