November 2017 - slf4j-dev - mailman3.qos.ch

JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
by Rory O'Donnell 28 Nov '17

28 Nov '17

Hi Ceki, *JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/* Notable changes since previous email. <http://bugs.openjdk.java.net/browse/JDK-8175094>JDK-8180019 <http://bugs.openjdk.java.net/browse/JDK-8180019> - *javadoc treats failure to access a URL as an error , not a warning.* If javadoc cannot access the contents of a URL provided with the -link or -linkoffline options,the tool will now report an error. Previously, the tool continued with a warning, producing incorrect documentation output. JDK-8175094 <http://bugs.openjdk.java.net/browse/JDK-8175094>*- **The java.security.acl APIs are deprecated, for removal**** * The deprecated java.security.acl APIs are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK-8175091 <http://bugs.openjdk.java.net/browse/JDK-8175091> *- The java.security.{Certificate,Identity,IdentityScope,Signer} APIs are deprecated, for removal* The deprecated java.security.{Certificate, Identity, IdentityScope, Signer} classes are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK 10 Schedule, Status & Features are available [1] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [2] *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/* <http://openjdk.java.net/projects/jdk8u/releases/8u162.html> *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://openjdk.java.net/projects/jdk/10/ [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-421) LoggerWrapper and subclasses perform argument substitution twice
by QOS.CH (JIRA) 27 Nov '17

27 Nov '17

[ https://jira.qos.ch/browse/SLF4J-421?page=com.atlassian.jira.plugin.system.… ] Kristin Clemens commented on SLF4J-421: --------------------------------------- I believe this can be solved by doing some extra work in MessageFormatter's arrayFormat method, before and after calling deeplyAppendParameter. We need to check to see if the current argument contains the formatting anchor, and if so, escape the anchor before appending it. Then we need to remove the argument from the argument array. If no one gets to this before I do, I'll submit a patch myself. Not sure when that'll be, though. > 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-421) LoggerWrapper and subclasses perform argument substitution twice
by QOS.CH (JIRA) 22 Nov '17

22 Nov '17

[ https://jira.qos.ch/browse/SLF4J-421?page=com.atlassian.jira.plugin.system.… ] Kristin Clemens commented on SLF4J-421: --------------------------------------- I believe this is the problem behind https://jira.qos.ch/browse/SLF4J-287, as that's how we discovered the bug in our project. When logging the entry of two maps, the first non-empty, the second empty, it appeared as though the second map had the same contents as the first map. > 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] ReproduceLog4j2Bug - foo,[{}] > // Actual > [ERROR] ReproduceLog4j2Bug - foo,[foo] > {code} > {code:java|title=Brackets First|borderStyle=solid} > log.error("{},{}", "[{}]", foo); > // Expected > [ERROR] ReproduceLog4j2Bug - [{}],foo > // Actual > [ERROR] ReproduceLog4j2Bug - [[{}]],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) 22 Nov '17

22 Nov '17

Kristin Clemens created SLF4J-421: ------------------------------------- Summary: 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 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. h2. Example 1, Brackets Second {code:java|borderStyle=solid} log.error("{},{}", foo, "[{}]"); {code} {code:title=Expected Output} [ERROR] ReproduceLog4j2Bug - foo,[{}] {code} {code:title=Actual Output} [ERROR] ReproduceLog4j2Bug - foo,[foo] {code} h2. Example 2, Brackets First {code:java|borderStyle=solid} log.error("{},{}", "[{}]", foo); {code} {code:title=Expected Output} [ERROR] ReproduceLog4j2Bug - [{}],foo {code} {code:title=Actual Output} [ERROR] ReproduceLog4j2Bug - [[{}]],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-420) Make a release with Automatic-Module-Name
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

Gael Lalire created SLF4J-420: --------------------------------- Summary: Make a release with Automatic-Module-Name Key: SLF4J-420 URL: https://jira.qos.ch/browse/SLF4J-420 Project: SLF4J Issue Type: Task Reporter: Gael Lalire Assignee: SLF4J developers list Priority: Trivial You can make a release with Automatic-Module-Name with 1.7 version so it can load logback and have the package name you choose in 1.8 beta. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-419) Make it possible to use a low priority LoggerFactory that is replaced in case a real slf4-implementation is available
by QOS.CH (JIRA) 04 Nov '17

04 Nov '17

[ https://jira.qos.ch/browse/SLF4J-419?page=com.atlassian.jira.plugin.system.… ] Jan S. commented on SLF4J-419: ------------------------------ Ok, if you don't understand the topic let's try it the other way round. How to solve the following problem: I have a Java library that can also be used stand-alone as program. This library/program uses slf4j as logging system. As it is a library it is strongly recommended not to add one of the SLF4J bindings as dependency to the library. However this means that when the library is executed as program slf4j-api defaults to the NopLoggerFactory and all logging is disabled which is a serious problem. Please describe the solution to solve this situation. > Make it possible to use a low priority LoggerFactory that is replaced in case a real slf4-implementation is available > --------------------------------------------------------------------------------------------------------------------- > > Key: SLF4J-419 > URL: https://jira.qos.ch/browse/SLF4J-419 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Jan S. > Assignee: SLF4J developers list > > The current implementation of slf4j-api defaults to the NOP_FALLBACK_FACTORY. This behavior can not be changed which is a severe problem for library projects that also contain executable code: > {quote}Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. > {quote} > because of this you can't link an slf4 implementation into it. Therefore code that gets executed from within that project uses the NOP_FALLBACK_FACTORY logger -> logging is disabled. > > I understand why slf4j-api does not contain a standard logger to System.out or System.err. But why is the NOP_FALLBACK_FACTORY hard-coded? > slf4j-api requires to have a possibility to define a LoggerFactory that is different to the default NOPLoggerFactory that will be used in case no other slf4j implementation is available. > > There my request is to make it possible to define "a low priority LoggerFactory" that is replaced in case a real slf4-implementation is available. > One possible way would be to allow modify LoggerFactory.NOP_FALLBACK_FACTORY directly or indirectly. > A second possibility would be to create some sort of marker (e.g. an Annotation) for an org.slf4j.impl.StaticLoggerBinder implementation that defines "this implementation should only be used if no other implementation can be found. > > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-419) Make it possible to use a low priority LoggerFactory that is replaced in case a real slf4-implementation is available
by QOS.CH (JIRA) 03 Nov '17

03 Nov '17

[ https://jira.qos.ch/browse/SLF4J-419?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-419. ------------------------------ Resolution: Won't Fix What are you trying to say? > Make it possible to use a low priority LoggerFactory that is replaced in case a real slf4-implementation is available > --------------------------------------------------------------------------------------------------------------------- > > Key: SLF4J-419 > URL: https://jira.qos.ch/browse/SLF4J-419 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Jan S. > Assignee: SLF4J developers list > > The current implementation of slf4j-api defaults to the NOP_FALLBACK_FACTORY. This behavior can not be changed which is a severe problem for library projects that also contain executable code: > {quote}Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. > {quote} > because of this you can't link an slf4 implementation into it. Therefore code that gets executed from within that project uses the NOP_FALLBACK_FACTORY logger -> logging is disabled. > > I understand why slf4j-api does not contain a standard logger to System.out or System.err. But why is the NOP_FALLBACK_FACTORY hard-coded? > slf4j-api requires to have a possibility to define a LoggerFactory that is different to the default NOPLoggerFactory that will be used in case no other slf4j implementation is available. > > There my request is to make it possible to define "a low priority LoggerFactory" that is replaced in case a real slf4-implementation is available. > One possible way would be to allow modify LoggerFactory.NOP_FALLBACK_FACTORY directly or indirectly. > A second possibility would be to create some sort of marker (e.g. an Annotation) for an org.slf4j.impl.StaticLoggerBinder implementation that defines "this implementation should only be used if no other implementation can be found. > > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-419) Make it possible to use a low priority LoggerFactory that is replaced in case a real slf4-implementation is available
by QOS.CH (JIRA) 03 Nov '17

03 Nov '17

Jan S. created SLF4J-419: ---------------------------- Summary: Make it possible to use a low priority LoggerFactory that is replaced in case a real slf4-implementation is available Key: SLF4J-419 URL: https://jira.qos.ch/browse/SLF4J-419 Project: SLF4J Issue Type: Improvement Components: Core API Reporter: Jan S. Assignee: SLF4J developers list The current implementation of slf4j-api defaults to the NOP_FALLBACK_FACTORY. This behavior can not be changed which is a severe problem for library projects that also contain executable code: {quote}Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. {quote} because of this you can't link an slf4 implementation into it. Therefore code that gets executed from within that project uses the NOP_FALLBACK_FACTORY logger -> logging is disabled. I understand why slf4j-api does not contain a standard logger to System.out or System.err. But why is the NOP_FALLBACK_FACTORY hard-coded? slf4j-api requires to have a possibility to define a LoggerFactory that is different to the default NOPLoggerFactory that will be used in case no other slf4j implementation is available. There my request is to make it possible to define "a low priority LoggerFactory" that is replaced in case a real slf4-implementation is available. One possible way would be to allow modify LoggerFactory.NOP_FALLBACK_FACTORY directly or indirectly. A second possibility would be to create some sort of marker (e.g. an Annotation) for an org.slf4j.impl.StaticLoggerBinder implementation that defines "this implementation should only be used if no other implementation can be found. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 10 b29 Early Access is available on jdk.java.net
by Rory O'Donnell 03 Nov '17

03 Nov '17

Hi Ceki, JDK 10 Early Access build 29 is available at : - jdk.java.net/10/ JDK 10 Early Access Release Notes are available [1] JDK 10 Schedule, Status & Features are available [2] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [3] , feedback via the mailing list to Mark please. <http://openjdk.java.net/projects/jdk8u/releases/8u162.html> Feedback - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://jdk.java.net/10/release-notes [2] http://openjdk.java.net/projects/jdk/10/ [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0