February 2019 - slf4j-dev - mailman3.qos.ch

[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

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

18 Feb '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Ceki, Are you going to use hyphen instead of underscore in the end? The updated version of maven-javadoc-plugin is ready for testing: 3.1.0-SNAPSHOT. Can you test that and let us know if you have any problems? I believe that a release is imminent. > 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

JDK 12: First Release Candidate available
by Rory O'Donnell 18 Feb '19

18 Feb '19

Hi Ceki, **OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at : - jdk.java.net/12/* **JDK 12: First Release Candidate [1]** * Per the JDK 12 schedule [2], we are now in Release Candidate Phase. * The stabilization repository, jdk/jdk12, is open for P1 bug fixes per the JDK Release Process (JEP 3) [3]. * All changes require approval via the Fix-Request Process [4]. * Release note additions since last email o Build 31 - can_pop_frame and can_force_early_return capabilities are disabled if JVMCI compiler is used (JDK-8218025 <https://bugs.openjdk.java.net/browse/JDK-8218025>) The JVMTI |can_pop_frame| and |can_force_early_return| capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (|PopFrame| and |ForceEarlyReturnXXX| functions) is not available to JVMTI agents. This issue is being fixed via JDK-8218885 <https://bugs.openjdk.java.net/browse/JDK-8218885> [https://bugs.openjdk.java.net/browse/JDK-8218885 <https://bugs.openjdk.java.net/browse/JDK-8218885>]. o Build 28: JDK-8212233 <https://bugs.openjdk.java.net/browse/JDK-8212233> : javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module." * Changes in this build. <http://hg.openjdk.java.net/jdk/jdk12/log?rev=reverse%28%22jdk-12%2B31%22%3A…> **OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at : - jdk.java.net/13/* * 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 updates * Build 8 o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() are unified across the platforms (JDK-8214918 <https://bugs.openjdk.java.net/browse/JDK-8214918>) o The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider. (JDK-8217835 <https://bugs.openjdk.java.net/browse/JDK-8217835>) * Build 7 o Change DOM parser to not resolve EntityReference and add Text node with DocumentBuilderFactory.setExpandEntityReferences(false) (JDK-8206132 <https://bugs.openjdk.java.net/browse/JDK-8206132>) * Build 6 o Base64.Encoder and Base64.Decoder methods can throw OutOfMemoryError (JDK-8210583 <https://bugs.openjdk.java.net/browse/JDK-8210583>) * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B7%22%3A%3A…> * FOSS Bugs fixed in recent builds o Build 6 : JDK-8216970 <https://bugs.openjdk.java.net/browse/JDK-8216970> : condy causes JVM crash o Build 7: JDK-8215577 <https://bugs.openjdk.java.net/browse/JDK-8215577> : Remove javadoc support for HTML 4 Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html [2] http://openjdk.java.net/projects/jdk/12/#Schedule [3] http://openjdk.java.net/jeps/3 [4] http://openjdk.java.net/jeps/3#Fix-Request-Process -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-424) extend "Logger" with fluent API to simplify logging calls with additional information (via MDC)
by QOS.CH (JIRA) 18 Feb '19

18 Feb '19

[ https://jira.qos.ch/browse/SLF4J-424?page=com.atlassian.jira.plugin.system.… ] Will Sargent commented on SLF4J-424: ------------------------------------ I've implemented much of this with wrappers in terse-logback: [https://github.com/tersesystems/terse-logback/blob/master/example/src/main/…] There's also the godaddy-logger API: [https://github.com/godaddy/godaddy-logger] and slf4j-fluent: https://github.com/ffissore/slf4j-fluent > extend "Logger" with fluent API to simplify logging calls with additional information (via MDC) > ----------------------------------------------------------------------------------------------- > > Key: SLF4J-424 > URL: https://jira.qos.ch/browse/SLF4J-424 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Christian Lorenz > Assignee: SLF4J developers list > > Hi, > > In our project we use SLF4J with Logback and logstash-logback-encoder. To use the advantages of ELK (Logstash) we set fields via MDC within the processing flow, but sometimes we also want to create custom fields (by using MDC) just for a single log message. Unfortunately the SLF4J Logger API does not provide a easy way to do that. > > To improve the API I've started implementing a fluent API to log messages. > [https://github.com/jackhammer2k/slf4j/commit/f3e768260b6f109d1f207e43c48e8c…] > > The approach should not affect the performance, but increases readability and extensibility. > The message builder can be extended for other stuff as well, but this is enough for us at least. > > To avoid breaking all existing implementations I changed the module name to "slf4j-api-jdk8" and implemented so far unused methods like "info()" as "default" interface methods. > The idea is to provide that extra package as an alternative for all Java 8 applications that want to replace their "slf4j-api" dependency. Like other libraries provide backwards-compatible versions for old JDKs. Its fully compatible with the whole SLF4J ecosystem. > > The module will be developed in the branch "slf4j-api-jdk8" forever. Thus during a release all modules will be released, master merged and only this module released from the branch as well. > > I would really like to see this extension within SLF4J instead of continuing with an own "extension library" used only internally. > > So far I've implemented just the info() method to show the idea, but if its accepted to be part of official SLF4J I will continue with the implementation. > > Cheers, > Christian -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-430) Remove org.slf4j.ext.EventData due to security issue
by QOS.CH (JIRA) 16 Feb '19

16 Feb '19

[ https://jira.qos.ch/browse/SLF4J-430?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-430. ------------------------------ Resolution: Fixed In 1.7.26 and 1.8.0-beta3 > Remove org.slf4j.ext.EventData due to security issue > ----------------------------------------------------- > > Key: SLF4J-430 > URL: https://jira.qos.ch/browse/SLF4J-430 > Project: SLF4J > Issue Type: Bug > Reporter: Ceki Gülcü > Assignee: Ceki Gülcü > Priority: Critical > Fix For: 1.7.26, 1.8.0-beta3 > > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0