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

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-487: ----------------------------------- Please see http://openjdk.java.net/jeps/238. {quote}A modular multi-release JAR file is a multi-release JAR file that has a module descriptor, module-info.class, in the root at the top, just like a modular JAR file (see the Packaging: Modular JAR section of JEP 261). In addition modular descriptors may be present in versioned areas.{quote} > module-info.class must be in root of jar, not META-INF/versions/9 > ----------------------------------------------------------------- > > Key: SLF4J-487 > URL: https://jira.qos.ch/browse/SLF4J-487 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 2.0.0-alpha1 > Environment: All environments > Reporter: Joakim Erdfelt > Assignee: SLF4J developers list > > Also reported here [https://github.com/qos-ch/slf4j/commit/fb418db538a4990#r37662713] > This triggers build warnings on javac. > The {{module-info.class}} shouldn't be in the {{META-INF/versions/9}} in the jar file, it should be in the root of the jar file. > Yes, I'm aware of -SLF4J-456-, but that's a bug in websphere's annotation parsing (a similar bug that *all* web containers have had to fix since [JEP238|https://openjdk.java.net/jeps/238] became a reality). > From maven (Eclipse Jetty 10.x is migrating to Slf4j 2.0.0-alpha1 btw). > {noformat} > [INFO] — maven-compiler-plugin:3.8.1:compile (default-compile) @ jetty-slf4j-impl — > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 9 source files to /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/target/classes > [WARNING] /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/src/main/java/module-info.java:[26,28] requires transitive directive for an automatic module > {noformat} > Using {{javac -Xlint:all ...}} on a project using {{slf4j-api-2.0.0-alpha1.jar}} with it's own {{module-info.class}} will show the above warning. > If you want a small example project, I'll be happy to make one for you. > The warning is because the {{module-info.class}} is not present at the root of the jar file (where it must be, despite the jigsaw devs brief suggestion in 2018 that {{META-INF/versions/9}} could be a solution for bytecode scanning problems, other tooling in the JDK hasn't caught up yet to that suggestion, even in JDK 14, even including {{javac}}). > javac sees {{slf4j-api-2.0.0-alpha1.jar}} as having no {{module-info.class}} and is instead using the jar as one with an automatic module name. > Manually repackaging {{slf4j-api-2.0.0-alpha1.jar}} with the {{module-info.class}} in the root fixes the javac warnings. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-487: ---------------------------------- {quote}javac sees slf4j-api-2.0.0-alpha1.jar as having no module-info.class and is instead using the jar as one with an automatic module name. {quote} I believe I had tested for the proper treatment of the module-info,class when placed under META-INF/versions/9. Let me check again. > module-info.class must be in root of jar, not META-INF/versions/9 > ----------------------------------------------------------------- > > Key: SLF4J-487 > URL: https://jira.qos.ch/browse/SLF4J-487 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 2.0.0-alpha1 > Environment: All environments > Reporter: Joakim Erdfelt > Assignee: SLF4J developers list > > Also reported here [https://github.com/qos-ch/slf4j/commit/fb418db538a4990#r37662713] > This triggers build warnings on javac. > The {{module-info.class}} shouldn't be in the {{META-INF/versions/9}} in the jar file, it should be in the root of the jar file. > Yes, I'm aware of -SLF4J-456-, but that's a bug in websphere's annotation parsing (a similar bug that *all* web containers have had to fix since [JEP238|https://openjdk.java.net/jeps/238] became a reality). > From maven (Eclipse Jetty 10.x is migrating to Slf4j 2.0.0-alpha1 btw). > {noformat} > [INFO] — maven-compiler-plugin:3.8.1:compile (default-compile) @ jetty-slf4j-impl — > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 9 source files to /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/target/classes > [WARNING] /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/src/main/java/module-info.java:[26,28] requires transitive directive for an automatic module > {noformat} > Using {{javac -Xlint:all ...}} on a project using {{slf4j-api-2.0.0-alpha1.jar}} with it's own {{module-info.class}} will show the above warning. > If you want a small example project, I'll be happy to make one for you. > The warning is because the {{module-info.class}} is not present at the root of the jar file (where it must be, despite the jigsaw devs brief suggestion in 2018 that {{META-INF/versions/9}} could be a solution for bytecode scanning problems, other tooling in the JDK hasn't caught up yet to that suggestion, even in JDK 14, even including {{javac}}). > javac sees {{slf4j-api-2.0.0-alpha1.jar}} as having no {{module-info.class}} and is instead using the jar as one with an automatic module name. > Manually repackaging {{slf4j-api-2.0.0-alpha1.jar}} with the {{module-info.class}} in the root fixes the javac warnings. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

Joakim Erdfelt created SLF4J-487: ------------------------------------ Summary: module-info.class must be in root of jar, not META-INF/versions/9 Key: SLF4J-487 URL: https://jira.qos.ch/browse/SLF4J-487 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0.0-alpha1 Environment: Also reported here [https://github.com/qos-ch/slf4j/commit/fb418db538a4990#r37662713] This triggers build warnings on javac. The {{module-info.class}} shouldn't be in the {{META-INF/versions/9}} in the jar file, it should be in the root of the jar file. Yes, I'm aware of -SLF4J-456-, but that's a bug in websphere's annotation parsing (a similar bug that *all* web containers have had to fix since [JEP238|https://openjdk.java.net/jeps/238] became a reality). >From maven (Eclipse Jetty 10.x is migrating to Slf4j 2.0.0-alpha1 btw). {noformat} [INFO] — maven-compiler-plugin:3.8.1:compile (default-compile) @ jetty-slf4j-impl — [INFO] Changes detected - recompiling the module! [INFO] Compiling 9 source files to /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/target/classes [WARNING] /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/src/main/java/module-info.java:[26,28] requires transitive directive for an automatic module {noformat} Using {{javac -Xlint:all ...}} on a project using {{slf4j-api-2.0.0-alpha1.jar}} with it's own {{module-info.class}} will show the above warning. If you want a small example project, I'll be happy to make one for you. The warning is because the {{module-info.class}} is not present at the root of the jar file (where it must be, despite the jigsaw devs brief suggestion in 2018 that {{META-INF/versions/9}} could be a solution for bytecode scanning problems, other tooling in the JDK hasn't caught up yet to that suggestion, even in JDK 14, even including {{javac}}). javac sees {{slf4j-api-2.0.0-alpha1.jar}} as having no {{module-info.class}} and is instead using the jar as one with an automatic module name. Manually repackaging {{slf4j-api-2.0.0-alpha1.jar}} with the {{module-info.class}} in the root fixes the javac warnings. Reporter: Joakim Erdfelt Assignee: SLF4J developers list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-486) deserialization of untrusted data risk on slf4j-log4j12
by QOS.CH (JIRA) 02 Mar '20

02 Mar '20

Juan Diego Morera created SLF4J-486: --------------------------------------- Summary: deserialization of untrusted data risk on slf4j-log4j12 Key: SLF4J-486 URL: https://jira.qos.ch/browse/SLF4J-486 Project: SLF4J Issue Type: Bug Affects Versions: 2.0.0-alpha1 Reporter: Juan Diego Morera Assignee: SLF4J developers list Hello, looks like latest version for slf4j-log4j12 (2.0.0-alpha1) has a dependency for log4j-1.2.17.jar and it will have the issue of deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. Related documentation: [https://nvd.nist.gov/vuln/detail/CVE-2019-17571] Please let me know if you have already this on you radar Regards . -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-485) LoggingEventBuilder addArgument() should take Supplier<?>, not Supplier<Object>
by QOS.CH (JIRA) 01 Mar '20

01 Mar '20

Christoffer Hammarström created SLF4J-485: --------------------------------------------- Summary: LoggingEventBuilder addArgument() should take Supplier<?>, not Supplier<Object> Key: SLF4J-485 URL: https://jira.qos.ch/browse/SLF4J-485 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0.0-alpha1 Reporter: Christoffer Hammarström Assignee: SLF4J developers list `addArgument(Supplier<Object>)` prevents passing in any `Supplier<? extends Object>`. Try the following JUnit 4 test: {noformat} import java.util.function.Supplier; import org.junit.Test; public class GenericsTest { @Test public void testObjectSupplier() { Supplier<Object> objectSupplier = () -> "Object"; Supplier<String> stringSupplier = () -> "String"; object(objectSupplier); //object(stringSupplier); // Uncommenting leads to compile failure //string(objectSupplier); // Uncommenting leads to compile failure string(stringSupplier); extendsObject(objectSupplier); // Works fine extendsObject(stringSupplier); // Works fine } private void object(Supplier<Object> objectSupplier) { System.out.println("object: "+objectSupplier.get()); } private void string(Supplier<String> stringSupplier) { System.out.println("string: "+stringSupplier.get()); } private void extendsObject(Supplier<?> extendsObjectSupplier) { System.out.println("extends object: "+extendsObjectSupplier.get()); } } {noformat} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0