January 2020 - slf4j-dev - mailman3.qos.ch

[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

[JIRA] (SLF4J-481) log4j-to-slf4j Null Throwable
by QOS.CH (JIRA) 02 Jan '20

02 Jan '20

Anton created SLF4J-481: --------------------------- Summary: log4j-to-slf4j Null Throwable Key: SLF4J-481 URL: https://jira.qos.ch/browse/SLF4J-481 Project: SLF4J Issue Type: Bug Environment: log4j-to-slf4j-2.11.1 Reporter: Anton Assignee: SLF4J developers list Priority: Minor In org.apache.logging.slf4j.SLF4JLogger.logMessage(...) Throwable t is passed to underlying SLF4J Logger implementation even if it is null, which causes the following method signature to apply, which is wrong: {code:java} Logger.trace(Marker marker, String format, Object arg1, Object arg2){code} There should be a check in this method, if Throwable t argument is null, then call: {code:java} Logger.trace(Marker marker, String format, Object arg){code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-479) JUL-SLF4J Bridge - sourceMethod not logged
by QOS.CH (JIRA) 02 Jan '20

02 Jan '20

[ https://jira.qos.ch/browse/SLF4J-479?page=com.atlassian.jira.plugin.system.… ] Anton commented on SLF4J-479: ----------------------------- Kind reminder. > JUL-SLF4J Bridge - sourceMethod not logged > ------------------------------------------ > > Key: SLF4J-479 > URL: https://jira.qos.ch/browse/SLF4J-479 > Project: SLF4J > Issue Type: Bug > Environment: JUL SLF4J Bridge 1.7.x > Reporter: Anton > Assignee: SLF4J developers list > > Consider an example from MSSQL JDBC Driver: > [https://github.com/microsoft/mssql-jdbc/blob/77f9f1086049e5ea4ff11fb5434fdd…] > {code:java} > loggerExternal.entering(getClassNameLogging(), "commit");{code} > > _Actual result_: The *sourceMethodName* ("commit") is not passed to the underlying SLF4J implementation, via JUL-SLF4J Bridge. > I.e. the sourceMethod is not logged in this case. > > _Expected result:_ JUL-SLF4J Bridge should pass sourceMethodName to SLF4J implementation. > Please also check if there are any other such attributes affected. > Suggested to fix in org.slf4j.bridge.SLF4JBridgeHandler. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0