- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-421) LoggerWrapper and subclasses perform argument substitution twice
by QOS.CH (JIRA) 09 Feb '20

09 Feb '20

[ https://jira.qos.ch/browse/SLF4J-421?page=com.atlassian.jira.plugin.system.… ] Jonathan Esssex commented on SLF4J-421: --------------------------------------- I just submitted a PR for this > LoggerWrapper and subclasses perform argument substitution twice > ----------------------------------------------------------------- > > Key: SLF4J-421 > URL: https://jira.qos.ch/browse/SLF4J-421 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.7.x > Environment: Java 8; haven't tested with earlier versions or Java 9. > Reporter: Kristin Clemens > Assignee: SLF4J developers list > Labels: logging, substitution > Fix For: 2.0.0-alpha2 > > Attachments: log4j2.xml, ReproduceSlf4jExtBug.java, results.txt > > > If a String containing "{}" (alone or with other characters) is passed to a LoggerWrapper log method that takes a format string and arguments, or to a subclass method that follows the same pattern, a situation can occur where an argument is substituted into the place of the argument containing the substitution brackets. That argument may be another string preceding the string with brackets, or if the string with brackets is first, it may be that argument itself. > This also occurs with log methods following this pattern even when a string format message is not expected, such as with XLogger entry and exit methods or LoggerWrapper single argument methods. > It's hard to describe effectively, so I'll provide some examples and test cases to help. > {code:java|title=Brackets Second|borderStyle=solid} > log.error("{},{}", foo, "[{}]"); > // Expected > [ERROR] ReproduceSlf4jBug - foo,[{}] > // Actual > [ERROR] ReproduceSlf4jBug - foo,[foo] > {code} > {code:java|title=Brackets First|borderStyle=solid} > log.error("{},{}", "[{}]", foo); > // Expected > [ERROR] ReproduceSlf4jBug - [{}],foo > // Actual > [ERROR] ReproduceSlf4jBug - [[{}]],foo > {code} > *In the attached tests, a basic org.slf4j.Logger is tested with the same arguments to provide a reference.* -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-421) LoggerWrapper and subclasses perform argument substitution twice
by QOS.CH (JIRA) 09 Feb '20

09 Feb '20

[ https://jira.qos.ch/browse/SLF4J-421?page=com.atlassian.jira.plugin.system.… ] Jonathan Esssex commented on SLF4J-421: --------------------------------------- This is surely a colossal headache for anyone doing much work with Json in Java... > LoggerWrapper and subclasses perform argument substitution twice > ----------------------------------------------------------------- > > Key: SLF4J-421 > URL: https://jira.qos.ch/browse/SLF4J-421 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.7.x > Environment: Java 8; haven't tested with earlier versions or Java 9. > Reporter: Kristin Clemens > Assignee: SLF4J developers list > Labels: logging, substitution > Attachments: log4j2.xml, ReproduceSlf4jExtBug.java, results.txt > > > If a String containing "{}" (alone or with other characters) is passed to a LoggerWrapper log method that takes a format string and arguments, or to a subclass method that follows the same pattern, a situation can occur where an argument is substituted into the place of the argument containing the substitution brackets. That argument may be another string preceding the string with brackets, or if the string with brackets is first, it may be that argument itself. > This also occurs with log methods following this pattern even when a string format message is not expected, such as with XLogger entry and exit methods or LoggerWrapper single argument methods. > It's hard to describe effectively, so I'll provide some examples and test cases to help. > {code:java|title=Brackets Second|borderStyle=solid} > log.error("{},{}", foo, "[{}]"); > // Expected > [ERROR] ReproduceSlf4jBug - foo,[{}] > // Actual > [ERROR] ReproduceSlf4jBug - foo,[foo] > {code} > {code:java|title=Brackets First|borderStyle=solid} > log.error("{},{}", "[{}]", foo); > // Expected > [ERROR] ReproduceSlf4jBug - [{}],foo > // Actual > [ERROR] ReproduceSlf4jBug - [[{}]],foo > {code} > *In the attached tests, a basic org.slf4j.Logger is tested with the same arguments to provide a reference.* -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-484) Do not mark alpha versions as "release" in maven
by QOS.CH (JIRA) 04 Feb '20

04 Feb '20

Janek created SLF4J-484: --------------------------- Summary: Do not mark alpha versions as "release" in maven Key: SLF4J-484 URL: https://jira.qos.ch/browse/SLF4J-484 Project: SLF4J Issue Type: Bug Components: slf4j-simple Reporter: Janek Assignee: SLF4J developers list Priority: Minor https://jcenter.bintray.com/org/slf4j/slf4j-simple/maven-metadata.xml Currently contains the following lines: {code:xml} <version>2.0.0-alpha1</version> <versioning> <latest>2.0.0-alpha1</latest> <release>2.0.0-alpha1</release> {code} But, if I am not misunderstanding maven versioning, it should actually be like this, so that the stable version is the default: {code:xml} <version>1.7.30</version> <versioning> <latest>2.0.0-alpha1</latest> <release>1.7.30</release> {code} I have so far only looked into slf4j-simple. but this might affect other dependencies as well. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-483) Wrong link for Jira
by QOS.CH (JIRA) 23 Jan '20

23 Jan '20

Martin Suska created SLF4J-483: ---------------------------------- Summary: Wrong link for Jira Key: SLF4J-483 URL: https://jira.qos.ch/browse/SLF4J-483 Project: SLF4J Issue Type: Bug Environment: Chrome browser + Win 10 Reporter: Martin Suska Assignee: SLF4J developers list Priority: Minor On [http://www.slf4j.org/bug-reporting.html] there is a link "Search for SLF4J bugs" with href {code:java} http://jira.qos.ch/issues/?jql=project%20%3D%20SLF4J {code} and when followed, JIRA is complaining about it. {code:java} Error in the JQL Query: The character '%' is a reserved JQL character. You must enclose it in a string or use the escape '\u0025' instead. (line 1, character 8) {code} I believe that proper link should be {code:java} https://jira.qos.ch/projects/SLF4J/ {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-482) Explicit parameter for throwable
by QOS.CH (JIRA) 23 Jan '20

23 Jan '20

Martin Suska created SLF4J-482: ---------------------------------- Summary: Explicit parameter for throwable Key: SLF4J-482 URL: https://jira.qos.ch/browse/SLF4J-482 Project: SLF4J Issue Type: Improvement Affects Versions: 1.7.29 Environment: Spring Boot Java application with only: {code:java} <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.2.2.RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> </dependencies> {code} in pom.xml Reporter: Martin Suska Assignee: SLF4J developers list Priority: Minor [This question|[https://stackoverflow.com/questions/45054154/logger-format-and-th…] on StackOverflow led me here as I had very the same question. That behaviour is kind of hidden - not described in JavaDoc. I believe it would be good to have {code:java} error(format, throwable, parameters){code} alternative (as throwable cannot be the last), which can call the existing one internally. I created this improvement just to make it easier for developers. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 76ee11: update link to Maven central
by Ceki Gulcu 19 Jan '20

19 Jan '20

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 76ee1112e5ec4d26227ba1f398e834d9ac51e2c4 https://github.com/qos-ch/slf4j/commit/76ee1112e5ec4d26227ba1f398e834d9ac51… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2020-01-19 (Sun, 19 Jan 2020) Changed paths: M slf4j-site/src/site/pages/download.html Log Message: ----------- update link to Maven central

1 0

JDK 14 is now in Rampdown Phase Two
by Rory O'Donnell 17 Jan '20

17 Jan '20

Hi Ceki, *Per the JDK 14 schedule , we are now in Rampdown Phase Two * *Please advise if you have any open high priority issues.* ** * The overall feature set is frozen. o No further JEPs will be targeted to this release o Per the JDK Release Process [1] we now turn our focus to P1 and P2 bugs. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] JDK 14 Early Access build 32 is availableat : - jdk.java.net/14/ * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Recent fixes that maybe of interest: o Build 32 + JDK-8230318: Better trust store usage + JDK-8225773: jdeps --check produces NPE if there is any missing module dependence # reported by JUnit5 + JDK-8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz() # duplicate of Apache Lucene's bug. o Build 31 + JDK-8235984: C2: assert(out->in(PhiNode::Region) == head || out->in(PhiNode::Region) == slow_head) failed: phi must be either part of the slow or the fast loop # duplicate of JDK-8236412 reported by Apache Lucene. + JDK-8236695: java.lang.Record should be declared with an explicit constructor JDK 15 Early Access build 6 is availableat : - jdk.java.net/15/ * These early-access , open-source builds are provided under the o 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/15/release-notes * Recent fixes that maybe of interest : o Build 6 + JDK-7143743: Potential memory leak with zip provider # Contributed by Jaikiran! + JDK-8213222: remove RMIConnectorServer.CREDENTIAL_TYPES + JDK-8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz() # duplicate of Apache Lucene's bug. o Build 5 + JDK-8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols + JDK-8236695: java.lang.Record should be declared with an explicit constructor *Invitation to Project Skara update and demo, January 22, 2020, 8:30 am PST * * See Joe Darcy's email [3]* * ** Rgds, Rory  [1] http://openjdk.java.net/jeps/3 [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-January/003846.html [3] https://mail.openjdk.java.net/pipermail/discuss/2020-January/005274.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

Proposal for SLF4J 2.0 Logger API
by Remko Popma 11 Jan '20

11 Jan '20

Hi Ceki, Sorry for raising this via the wrong channel initially. If there is still time for SLF4J 2.0, I propose changing the Logger methods that take a String to accept an Object instead (excl. the methods that take format params); this enables various use cases and optimizations in SLF4J implementations that are not possible with the String-based API. One potential use case is a garbage-free implementations of the API. A Logger implementation could check if the specified Object implements java.lang.CharSequence, for example, and extract the message text without allocating a temp String object. GC-sensitive apps could then log StringBuilder objects, for example. Another use case is binary logging; if the logging implementation has an efficient way to map domain objects to a binary representation (as opposed to a textual representation), then this could be both faster and produce more compact output, which may be of interest to a certain type of applications. The binary presentation could be converted back to text offline or on-demand. Such use cases are not possible if the SLF4J API only provides methods that accept Strings: information has been lost by the time the logging implementation is invoked. I cannot think of any downside, only upside, of replacing methods like Logger.info(String) with Logger.info(Object) in the API. For API users this would be a backwards compatible change. API implementations would need to do something extra to get the textual representation from the specified Object, but not much - this could be as simple as calling toString on it. However, an Object-based API opens the door for various use cases and optimizations in SLF4J implementations that are otherwise not possible, as suggested above. I'm hoping that the 2.0 major release would be an opportunity for such changes... Thoughts? Remko.

5 14

1.8.0-beta5 release
by George Suaridze 11 Jan '20

11 Jan '20

Hello! I would like to know is there any plans to build/publish 1.8.0-beta5 release? It has some fixes which is very critical to us. Regards, George

2 2

JDK 14 Early Access build 30 & JDK 15 Early Access build 4 are available.
by Rory O'Donnell 06 Jan '20

06 Jan '20

Hi Ceki, Happy New Year ! *Per the JDK 14 schedule , we are now in Rampdown Phase One* *Please advise if you have found any issues while testing the latest Early Access build. * * The overall feature set is frozen. o No further JEPs will be targeted to this release o For more details , see Mark Reinhold's email to jdk-dev mailing list [1] *JDK 14 **Early Access build 30 **is available**at : - jdk.java.net/14/* * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Release notes o https://jdk.java.net/14/release-notes * Recent fixes that might be of interest o Build 29: + JDK-8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR o Build 28: + JDK-8234049: Implementation of Memory Access API (Incubator) + JDK-8235668: LineNumberReader#getLineNumber() returns wrong line number (one fewer) in Lucene test # Reported by Apache Lucene *JDK 15 **Early Access build 4 **is available**at : - jdk.java.net/15/* * These early-access , open-source builds are provided under the o 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/15/release-notes The Quality Outreach Report for Decemeber 2019 was published since the last email * https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Decem… * Many thanks to all those who contributed to testing, logging bugs etc against the Early Access builds. * * Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003795.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0