- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-233) log4j-over-slf4j silently ignores Throwables in some cases
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-233?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-233. ------------------------------ Resolution: Fixed Fixed in [commit a822fd76|https://github.com/qos-ch/slf4j/commit/a822fd76] > log4j-over-slf4j silently ignores Throwables in some cases > ---------------------------------------------------------- > > Key: SLF4J-233 > URL: https://jira.qos.ch/browse/SLF4J-233 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.6.x > Environment: Operating System: Mac OS X 10.3 > Platform: PC > Reporter: John Vasileff > Assignee: Ceki Gülcü > Priority: Minor > Fix For: 1.8.0-beta5 > > > For non LocationAwareLoggers, Throwables are silently ignored. See: > https://github.com/qos-ch/slf4j/blob/v_1.6.2/log4j-over-slf4j/src/main/java… > For trace(Object message, Throwable t), the Throwable is silently ignored. See: > https://github.com/qos-ch/slf4j/blob/v_1.6.2/log4j-over-slf4j/src/main/java… -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Ceki, I left some comments on that commit. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta4 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-428. ------------------------------ Resolution: Fixed Solved in [commit fb418db538|https://github.com/qos-ch/slf4j/commit/fb418db538] > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.7.26, 1.8.0-beta4 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-456) SLF4J 1.8 on JVMs < 9
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-456?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-456. ------------------------------ Resolution: Fixed Fixed in [commit fb418|https://github.com/qos-ch/slf4j/commit/fb418db538a4990] > SLF4J 1.8 on JVMs < 9 > --------------------- > > Key: SLF4J-456 > URL: https://jira.qos.ch/browse/SLF4J-456 > Project: SLF4J > Issue Type: Bug > Components: Core API, jcl-over-slf4j > Affects Versions: 1.8.0-beta2 > Reporter: Thorsten Heit > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta4 > > > When I use slf4j-1.8.0-beta2 in an application that is being deployed to our Websphere 9 server, I see error messages in the deployment manager console: > {noformat} > (...) > [2/18/19 15:51:31:862 CET] 000022bd WSModuleDescr E WSWS7011E: The configuration for the myapp-war-2019.4.0-SNAPSHOT.war application module cannot load correctly. > The following error occurred: com.ibm.ws.metadata.annotations.AnnotationException: Annotation processing failed for class: module-info.class > at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:883) > at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationDataForZippedArchive(AnnotationConfigReader.java:766) > at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:696) > at com.ibm.ws.metadata.annotations.AnnotationConfigReader.populateModuleData(AnnotationConfigReader.java:353) > at com.ibm.ws.metadata.MetaDataOrchestrator.getModuleData(MetaDataOrchestrator.java:112) > at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.getMDO(WASAnnotationCollector.java:258) > at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.collect(WASAnnotationCollector.java:146) > at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getClassDataObjects(WSModuleDescriptorImpl.java:1458) > at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.initDBCMap(WSModuleDescriptorImpl.java:2153) > at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.buildJAXWSServiceRefs(WSModuleDescriptorImpl.java:1137) > at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl._containsWebServiceClients(WSModuleDescriptorImpl.java:639) > at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.containsWebServiceClients(WSModuleDescriptorImpl.java:611) > at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeModuleCache(WSCacheWriter.java:583) > at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeApplicationCache(WSCacheWriter.java:242) > at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeApplicationCache(WSCacheWriter.java:167) > at com.ibm.ws.websvcs.deploy.PersistentStorageInstallSaveTask.performTask(PersistentStorageInstallSaveTask.java:196) > at com.ibm.ws.management.application.sync.AppBinaryProcessor$ExpandApp.expand(AppBinaryProcessor.java:1770) > at com.ibm.ws.management.application.sync.AppBinaryProcessor$AppBinThread.run(AppBinaryProcessor.java:1276) > at java.lang.Thread.run(Thread.java:811) > Caused by: java.lang.IllegalArgumentException > at org.objectweb.asm.ClassReader.<init>(Unknown Source) > at org.objectweb.asm.ClassReader.<init>(Unknown Source) > at org.objectweb.asm.ClassReader.<init>(Unknown Source) > at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:836) > ... 18 more > (...){noformat} > Switching back to the older 1.7.25 version lets this error message disappear. > The reason is that Websphere (still) uses Java 8 which cannot parse / process the {{module-info.class}} that was compiled with Java 9. > My WAR inside the EAR actually only uses {{slf4j-api-1.8.0-beta2.jar}} and {{jcl-over-slf4j-1.8.0-beta2.jar}}, but I assume that all Jars containing this file are affected. > Solution: > Move the class to {{META-INF/versions/9}} and mark the resulting jar as being a multi-release jar. See the example in [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirel…] for how to do this -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Ceki, I'm not sure when this changed but keep in mind that JDK 9 and 10 are no longer supported by Oracle. JDK 11 is the first LTS release and it never had the reserved keyword issue as far as I know. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.7.26, 1.8.0-beta4 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-428: ---------------------------------- [~cowwoc] et al, Does anyone know when was the reserved keyword issue solved in the JDK? > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.7.26, 1.8.0-beta4 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-456) SLF4J 1.8 on JVMs < 9
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

Thorsten Heit created SLF4J-456: ----------------------------------- Summary: SLF4J 1.8 on JVMs < 9 Key: SLF4J-456 URL: https://jira.qos.ch/browse/SLF4J-456 Project: SLF4J Issue Type: Bug Components: Core API, jcl-over-slf4j Affects Versions: 1.8.0-beta2 Reporter: Thorsten Heit Assignee: SLF4J developers list When I use slf4j-1.8.0-beta2 in an application that is being deployed to our Websphere 9 server, I see error messages in the deployment manager console: {noformat} (...) [2/18/19 15:51:31:862 CET] 000022bd WSModuleDescr E WSWS7011E: The configuration for the myapp-war-2019.4.0-SNAPSHOT.war application module cannot load correctly. The following error occurred: com.ibm.ws.metadata.annotations.AnnotationException: Annotation processing failed for class: module-info.class at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:883) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationDataForZippedArchive(AnnotationConfigReader.java:766) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:696) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.populateModuleData(AnnotationConfigReader.java:353) at com.ibm.ws.metadata.MetaDataOrchestrator.getModuleData(MetaDataOrchestrator.java:112) at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.getMDO(WASAnnotationCollector.java:258) at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.collect(WASAnnotationCollector.java:146) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getClassDataObjects(WSModuleDescriptorImpl.java:1458) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.initDBCMap(WSModuleDescriptorImpl.java:2153) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.buildJAXWSServiceRefs(WSModuleDescriptorImpl.java:1137) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl._containsWebServiceClients(WSModuleDescriptorImpl.java:639) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.containsWebServiceClients(WSModuleDescriptorImpl.java:611) at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeModuleCache(WSCacheWriter.java:583) at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeApplicationCache(WSCacheWriter.java:242) at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeApplicationCache(WSCacheWriter.java:167) at com.ibm.ws.websvcs.deploy.PersistentStorageInstallSaveTask.performTask(PersistentStorageInstallSaveTask.java:196) at com.ibm.ws.management.application.sync.AppBinaryProcessor$ExpandApp.expand(AppBinaryProcessor.java:1770) at com.ibm.ws.management.application.sync.AppBinaryProcessor$AppBinThread.run(AppBinaryProcessor.java:1276) at java.lang.Thread.run(Thread.java:811) Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.<init>(Unknown Source) at org.objectweb.asm.ClassReader.<init>(Unknown Source) at org.objectweb.asm.ClassReader.<init>(Unknown Source) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:836) ... 18 more (...){noformat} Switching back to the older 1.7.25 version lets this error message disappear. The reason is that Websphere (still) uses Java 8 which cannot parse / process the {{module-info.class}} that was compiled with Java 9. My WAR inside the EAR actually only uses {{slf4j-api-1.8.0-beta2.jar}} and {{jcl-over-slf4j-1.8.0-beta2.jar}}, but I assume that all Jars containing this file are affected. Solution: Move the class to {{META-INF/versions/9}} and mark the resulting jar as being a multi-release jar. See the example in [https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirel…] for how to do this -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

SLF4J 1.8 on JVMs < 9
by Thorsten Heit 19 Feb '19

19 Feb '19

Hi, I just joined this list, so first hi from Germany ;-) When I use slf4j-1.8.0-beta2 in an application that is being deployed to our Websphere 9 server, I see error messages in the deployment manager console: (...) [2/18/19 15:51:31:862 CET] 000022bd WSModuleDescr E WSWS7011E: The configuration for the myapp-war-2019.4.0-SNAPSHOT.war application module cannot load correctly. The following error occurred: com.ibm.ws.metadata.annotations.AnnotationException: Annotation processing failed for class: module-info.class at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:883) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationDataForZippedArchive(AnnotationConfigReader.java:766) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:696) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.populateModuleData(AnnotationConfigReader.java:353) at com.ibm.ws.metadata.MetaDataOrchestrator.getModuleData(MetaDataOrchestrator.java:112) at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.getMDO(WASAnnotationCollector.java:258) at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.collect(WASAnnotationCollector.java:146) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getClassDataObjects(WSModuleDescriptorImpl.java:1458) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.initDBCMap(WSModuleDescriptorImpl.java:2153) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.buildJAXWSServiceRefs(WSModuleDescriptorImpl.java:1137) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl._containsWebServiceClients(WSModuleDescriptorImpl.java:639) at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.containsWebServiceClients(WSModuleDescriptorImpl.java:611) at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeModuleCache(WSCacheWriter.java:583) at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeApplicationCache(WSCacheWriter.java:242) at com.ibm.ws.websvcs.deploy.WSCacheWriter.writeApplicationCache(WSCacheWriter.java:167) at com.ibm.ws.websvcs.deploy.PersistentStorageInstallSaveTask.performTask(PersistentStorageInstallSaveTask.java:196) at com.ibm.ws.management.application.sync.AppBinaryProcessor$ExpandApp.expand(AppBinaryProcessor.java:1770) at com.ibm.ws.management.application.sync.AppBinaryProcessor$AppBinThread.run(AppBinaryProcessor.java:1276) at java.lang.Thread.run(Thread.java:811) Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.ClassReader.<init>(Unknown Source) at org.objectweb.asm.ClassReader.<init>(Unknown Source) at org.objectweb.asm.ClassReader.<init>(Unknown Source) at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:836) ... 18 more (...) Switching back to the older 1.7.25 version lets this error message disappear. The reason is that Websphere uses Java 8 which cannot parse / process the module-info.class that was compiled with Java 9. Solution for these kinds of problems: Move the class to META-INF/versions/9 and mark the resulting Jar as a multi-release. See [1] for how to do this. What do you think? I can create a pull request on Github if you like. Regards Thorsten [1] https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirel…

2 2

[JIRA] (SLF4J-451) org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data.
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-451?page=com.atlassian.jira.plugin.system.… ] Federico Fissore commented on SLF4J-451: ---------------------------------------- Please check again, it's available now. Between deploy to central and public availability, maven servers have to sync and that may take some hours > org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SLF4J-451 > URL: https://jira.qos.ch/browse/SLF4J-451 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.8.0-beta2 > Environment: Linux > Reporter: Narayan > Assignee: SLF4J developers list > Labels: logging > > More details is available in [https://nvd.nist.gov/vuln/detail/CVE-2018-8088|https://nvd.nist.gov/vuln/de…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-451) org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data.
by QOS.CH (JIRA) 18 Feb '19

18 Feb '19

[ https://jira.qos.ch/browse/SLF4J-451?page=com.atlassian.jira.plugin.system.… ] Nathan Jensen commented on SLF4J-451: ------------------------------------- Thank you for fixing the CVE for 1.7 branch. Even though it did not apply to our project, it showed up in security scans and required explanations to managers about how it did not affect our project. I received the email that 1.7.26 is available but it does not appear to be on the downloads page or maven central. Can you please update those locations to provide 1.7.26? Thank you. > org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SLF4J-451 > URL: https://jira.qos.ch/browse/SLF4J-451 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.8.0-beta2 > Environment: Linux > Reporter: Narayan > Assignee: SLF4J developers list > Labels: logging > > More details is available in [https://nvd.nist.gov/vuln/detail/CVE-2018-8088|https://nvd.nist.gov/vuln/de…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0