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

[qos-ch/slf4j] 2ff447: doc improvements
by Ceki Gulcu 25 Apr '17

25 Apr '17

Branch: refs/heads/1_8_0-SNAPSHOT Home: https://github.com/qos-ch/slf4j Commit: 2ff447be268ab736dd64d908d4ec922292341c8e https://github.com/qos-ch/slf4j/commit/2ff447be268ab736dd64d908d4ec92229234… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-04-26 (Wed, 26 Apr 2017) Changed paths: M slf4j-site/src/site/pages/codes.html M slf4j-site/src/site/pages/faq.html M slf4j-site/src/site/pages/news.html Log Message: ----------- doc improvements

1 0

[JIRA] (SLF4J-407) Jigsaw modules contain clashing package
by QOS.CH (JIRA) 25 Apr '17

25 Apr '17

[ https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-407: ---------------------------------- The `org.slf4j.jul` package is no longer exported by slf4j-jdk14. See [commit 3823bd|https://github.com/qos-ch/slf4j/commit/3823bd18e8829e72bf4a63cca62eb] As for the `org.slf4j.impl` packages included in various slf4j artifacts, I am afraid these cannot be changed. The reasons are mentioned in this [faq entry|https://www.slf4j.org/faq.html#changesInVersion18] Please let me know if the reasons are clear. > Jigsaw modules contain clashing package > --------------------------------------- > > Key: SLF4J-407 > URL: https://jira.qos.ch/browse/SLF4J-407 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.8.0-alpha1 > Reporter: Stephen Colebourne > Assignee: SLF4J developers list > Fix For: 1.8.0-alpha2 > > > Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules that contain the same package, so this will be a problem. > I know that SLF4J does not intend users to load both of these modules at the same time. But the current setup means that it will be the JPMS runtime that rejects it, meaning that there is no chance for SLF4J to output a helpful message (as I believe it does today). > The solution to this would appear to be to move the `org.slf4j.impl` package to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not exported, this should not affect any user code (except code that would have been affected anyway). > I imagine this affects other slf4j artifacts. > I also note that [this module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-…] exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop do not export their package). > See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for more information on naming. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 3823bd: no need to export 'org.slf4j.jul' package
by Ceki Gulcu 25 Apr '17

25 Apr '17

Branch: refs/heads/1_8_0-SNAPSHOT Home: https://github.com/qos-ch/slf4j Commit: 3823bd18e8829e72bf4a63cca62eb6c27e9132b6 https://github.com/qos-ch/slf4j/commit/3823bd18e8829e72bf4a63cca62eb6c27e91… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-04-25 (Tue, 25 Apr 2017) Changed paths: M slf4j-jdk14/src/main/java/module-info.java Log Message: ----------- no need to export 'org.slf4j.jul' package

1 0

[JIRA] (SLF4J-408) Incorrect module name for log4j-over-slf4j
by QOS.CH (JIRA) 25 Apr '17

25 Apr '17

[ https://jira.qos.ch/browse/SLF4J-408?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-408. ------------------------------ Resolution: Fixed Resolved by [commit eec2336e6|https://github.com/qos-ch/slf4j/commit/eec2336e6287288276cc4975] > Incorrect module name for log4j-over-slf4j > ------------------------------------------ > > Key: SLF4J-408 > URL: https://jira.qos.ch/browse/SLF4J-408 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.8.0-alpha1 > Reporter: Stephen Colebourne > Assignee: SLF4J developers list > Fix For: 1.8.0-alpha2 > > > I need to write this exact use case up in more detail, but see the comments section of my [naming article|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] Basically, the module name must be the same for both the real log4j and the "fake" one being supplied by this artifact. > This is because the purpose of this module is to replace the log4j one, and because two packages cannot be in the same module. It is up to the build system, ie. Maven, to select the correct artifact to fulfill a given module name. > Based on discussions on the commons-dev mailing list, I'm proposing [these as the module names|http://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3CC…] notably `org.apache.logging.log4j`. (This is based on my super-package reverse-DNS standard naming approach) > Thus the module-info.java file needs to change from a module name of `org.slf4j.log4j_over_slf4j` to `org.apache.logging.log4j`. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] eec233: fix SLF4J-408
by Ceki Gulcu 25 Apr '17

25 Apr '17

Branch: refs/heads/1_8_0-SNAPSHOT Home: https://github.com/qos-ch/slf4j Commit: eec2336e6287288276cc49750d2ab5ae098cddc1 https://github.com/qos-ch/slf4j/commit/eec2336e6287288276cc49750d2ab5ae098c… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-04-25 (Tue, 25 Apr 2017) Changed paths: M jcl-over-slf4j/src/main/java/module-info.java M log4j-over-slf4j/src/main/java/module-info.java M slf4j-site/src/site/pages/faq.html Log Message: ----------- fix SLF4J-408 Commit: ec8419c5163ff50999b17ceca0f27fd49553d079 https://github.com/qos-ch/slf4j/commit/ec8419c5163ff50999b17ceca0f27fd49553… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-04-25 (Tue, 25 Apr 2017) Changed paths: M slf4j-site/src/site/pages/news.html Log Message: ----------- news.html update Compare: https://github.com/qos-ch/slf4j/compare/d168ea7f128e...ec8419c5163f

1 0

[JIRA] (SLF4J-408) Incorrect module name for log4j-over-slf4j
by QOS.CH (JIRA) 25 Apr '17

25 Apr '17

[ https://jira.qos.ch/browse/SLF4J-408?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-408: ---------------------------------- I am very much convinced by your argument that an artifact B intended to replace artifact A should have the same module name. In the case of {{jcl-over-slf4j}} which is intended to be a binary replacement for {{commons-logging}}, the former artifact *must* have the same module name as the "replacee". However, given that {{commons-logging}} has not yet been modularized, one can only guess that the module name will be 'org.apache.commons.logging'; without any assurances. By the same logic, {{log4j-over-slf4j}} should have the same module name as that of log4jv1. Given that log4j v1 is no longer developed, it is expected to remain as an auto-module forever with the presumed module name 'log4j'. > Incorrect module name for log4j-over-slf4j > ------------------------------------------ > > Key: SLF4J-408 > URL: https://jira.qos.ch/browse/SLF4J-408 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.8.0-alpha1 > Reporter: Stephen Colebourne > Assignee: SLF4J developers list > Fix For: 1.8.0-alpha2 > > > I need to write this exact use case up in more detail, but see the comments section of my [naming article|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] Basically, the module name must be the same for both the real log4j and the "fake" one being supplied by this artifact. > This is because the purpose of this module is to replace the log4j one, and because two packages cannot be in the same module. It is up to the build system, ie. Maven, to select the correct artifact to fulfill a given module name. > Based on discussions on the commons-dev mailing list, I'm proposing [these as the module names|http://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3CC…] notably `org.apache.logging.log4j`. (This is based on my super-package reverse-DNS standard naming approach) > Thus the module-info.java file needs to change from a module name of `org.slf4j.log4j_over_slf4j` to `org.apache.logging.log4j`. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] d168ea: start work on 1.8.0-alpha2-SNAPSHOT
by Ceki Gulcu 25 Apr '17

25 Apr '17

Branch: refs/heads/1_8_0-SNAPSHOT Home: https://github.com/qos-ch/slf4j Commit: d168ea7f128ebe6485048524b52a975be439375e https://github.com/qos-ch/slf4j/commit/d168ea7f128ebe6485048524b52a975be439… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-04-25 (Tue, 25 Apr 2017) Changed paths: M integration/pom.xml M jcl-over-slf4j/pom.xml M jul-to-slf4j/pom.xml M log4j-over-slf4j/pom.xml M osgi-over-slf4j/pom.xml M pom.xml M slf4j-api/pom.xml M slf4j-ext/pom.xml M slf4j-jdk14/pom.xml M slf4j-log4j12/pom.xml M slf4j-migrator/pom.xml M slf4j-nop/pom.xml M slf4j-simple/pom.xml M slf4j-site/pom.xml Log Message: ----------- start work on 1.8.0-alpha2-SNAPSHOT

1 0

Logback doesn't work with SLF4J?
by Ralph Goers 24 Apr '17

24 Apr '17

I have a test that is trying to use SLF4J 1.8.0-alpha1 and am getting the error below - which implies that SLF4J doesn’t work with Logback. Why isn’t the SLF4J binding backward compatible? SLF4J: No SLF4J providers were found. SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details. SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to 1.8. SLF4J: Ignoring binding found at [jar:file:/Users/rgoers/.m2/repository/ch/qos/logback/logback-classic/1.2.2/logback-classic-1.2.2.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation. Ralph

2 3

[JIRA] (SLF4J-408) Incorrect module name for log4j-over-slf4j
by QOS.CH (JIRA) 23 Apr '17

23 Apr '17

[ https://jira.qos.ch/browse/SLF4J-408?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-408: ----------------------------------- I guess I understand but I have a bad feeling that this is going to be very confusing for users. > Incorrect module name for log4j-over-slf4j > ------------------------------------------ > > Key: SLF4J-408 > URL: https://jira.qos.ch/browse/SLF4J-408 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.8.0-alpha1 > Reporter: Stephen Colebourne > Assignee: SLF4J developers list > > I need to write this exact use case up in more detail, but see the comments section of my [naming article|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] Basically, the module name must be the same for both the real log4j and the "fake" one being supplied by this artifact. > This is because the purpose of this module is to replace the log4j one, and because two packages cannot be in the same module. It is up to the build system, ie. Maven, to select the correct artifact to fulfill a given module name. > Based on discussions on the commons-dev mailing list, I'm proposing [these as the module names|http://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3CC…] notably `org.apache.logging.log4j`. (This is based on my super-package reverse-DNS standard naming approach) > Thus the module-info.java file needs to change from a module name of `org.slf4j.log4j_over_slf4j` to `org.apache.logging.log4j`. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-408) Incorrect module name for log4j-over-slf4j
by QOS.CH (JIRA) 23 Apr '17

23 Apr '17

[ https://jira.qos.ch/browse/SLF4J-408?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-408: ------------------------------------------ If I understand how slf4j works correctly, the slf4j jar file pretends to be the log4j jar file. When you take modules into account, that means it must use the same module name. This isn't new - slf4j uses Apache's package names today. ie. the only way to make JPMS modules work is to name them after the super-package they contain. In practice, Maven will have to have a way to select which artifact to use when two map to the same module name. > Incorrect module name for log4j-over-slf4j > ------------------------------------------ > > Key: SLF4J-408 > URL: https://jira.qos.ch/browse/SLF4J-408 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.8.0-alpha1 > Reporter: Stephen Colebourne > Assignee: SLF4J developers list > > I need to write this exact use case up in more detail, but see the comments section of my [naming article|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] Basically, the module name must be the same for both the real log4j and the "fake" one being supplied by this artifact. > This is because the purpose of this module is to replace the log4j one, and because two packages cannot be in the same module. It is up to the build system, ie. Maven, to select the correct artifact to fulfill a given module name. > Based on discussions on the commons-dev mailing list, I'm proposing [these as the module names|http://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3CC…] notably `org.apache.logging.log4j`. (This is based on my super-package reverse-DNS standard naming approach) > Thus the module-info.java file needs to change from a module name of `org.slf4j.log4j_over_slf4j` to `org.apache.logging.log4j`. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0