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

Prepared branch for slf4j 2.0
by Federico Fissore 02 May '19

02 May '19

Hi Ceki I prepared the branch for slf4j 2.0. I cannot make a PR that targets a non existing branch: can you make one? Code is available at https://github.com/ffissore/slf4j/tree/2.0.0-SNAPSHOT I've replaced occurrences of java 1.5 and 1.6 to 1.8 and I've included slf4j fluent Let me know what you think federico

3 11

[JIRA] (SLF4J-457) OSGi support in SLF4J 1.8
by QOS.CH (JIRA) 21 Feb '19

21 Feb '19

Björn Kautler created SLF4J-457: ----------------------------------- Summary: OSGi support in SLF4J 1.8 Key: SLF4J-457 URL: https://jira.qos.ch/browse/SLF4J-457 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.8.0-beta4 Environment: Reporter: Björn Kautler Assignee: SLF4J developers list Please support the native OSGi service loader mechanism for finding and registering implementations. As this needs some work, an intermediary quick-fix would be to depend on the service loader mediator. For this a PR exists at https://github.com/qos-ch/slf4j/pull/198. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-445) Skip SubstituteLogger from caller data (slf4j-jdk14)
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-445?page=com.atlassian.jira.plugin.system.… ] Guillaume Grossetie commented on SLF4J-445: ------------------------------------------- Awesome thanks @ceki > Skip SubstituteLogger from caller data (slf4j-jdk14) > ---------------------------------------------------- > > Key: SLF4J-445 > URL: https://jira.qos.ch/browse/SLF4J-445 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.7.25 > Environment: Slf4j-jdk14 binding > Reporter: Alexander Yevsyukov > Assignee: Ceki Gülcü > Labels: consoleoutput, substitution > Fix For: 1.8.0-beta5 > > > When using \{\{SubstituteLogger}} with \{\{JDK14LoggerAdapter}} (obtained regularly via \{\{LoggerFactory}}) the output always gives \{\{SubstituteLogger}} as the caller. A programmer would be interested in the class/method of his code. > The issue is that \{\{JDK14LoggerAdapter.fillCallerData()}} does not take into account that \{\{SubstituteLogger}} can be the direct caller, and it is needed to go one level deeper. > This issue is similar to [one reported to LogBack|https://jira.qos.ch/browse/LOGBACK-1100]. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-445) Skip SubstituteLogger from caller data (slf4j-jdk14)
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-445?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-445. ------------------------------ Resolution: Fixed Fixed in [commit 9928d|https://github.com/qos-ch/slf4j/commit/9928d80daf022e] > Skip SubstituteLogger from caller data (slf4j-jdk14) > ---------------------------------------------------- > > Key: SLF4J-445 > URL: https://jira.qos.ch/browse/SLF4J-445 > Project: SLF4J > Issue Type: Bug > Components: Implementations > Affects Versions: 1.7.25 > Environment: Slf4j-jdk14 binding > Reporter: Alexander Yevsyukov > Assignee: Ceki Gülcü > Labels: consoleoutput, substitution > Fix For: 1.8.0-beta5 > > > When using \{\{SubstituteLogger}} with \{\{JDK14LoggerAdapter}} (obtained regularly via \{\{LoggerFactory}}) the output always gives \{\{SubstituteLogger}} as the caller. A programmer would be interested in the class/method of his code. > The issue is that \{\{JDK14LoggerAdapter.fillCallerData()}} does not take into account that \{\{SubstituteLogger}} can be the direct caller, and it is needed to go one level deeper. > This issue is similar to [one reported to LogBack|https://jira.qos.ch/browse/LOGBACK-1100]. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-449) Unexpected execution environment J2SE-1.6
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-449?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-449. ------------------------------ Resolution: Fixed Fixed in [commit 458525e2e194e8|https://github.com/qos-ch/slf4j/commit/458525e2e194e8] > Unexpected execution environment J2SE-1.6 > ----------------------------------------- > > Key: SLF4J-449 > URL: https://jira.qos.ch/browse/SLF4J-449 > Project: SLF4J > Issue Type: Bug > Components: Core API, Implementations > Affects Versions: 1.8.0-beta2 > Environment: OSGi Execution Environments and specifically, Eclipse Tycho and OSGi plugins and bundles. > Reporter: Larissa Smirnova > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta5 > > > The Bundle-RequiredExecutionEnvironment in the slf4j-api and slf4j-integration are set to J2SE-1.6. The Standard Eclipse OSGi Execution Environment for Java 6 is JavaSE-1.6 and not J2SE-1.6. Due to this error, builds using the Eclipse OSGi Execution Environment value will have an error of an unrecognized Execution Environment. One example is using Eclipse Tycho to build Eclipse plugins and OSGi bundles. > The issue has appeared after commit ab389a9b82abe35034a3026c7eb0d4b9a07b4ae7 updated Bundle-RequiredExecutionEnvironment value from J2SE-1.5 to J2SE-1.6. > The Standard Execution Environments are listed at: [https://wiki.eclipse.org/Execution_Environments#Standard_Execution_Environm…] > As part of this defect submission, a fix with the changes to correct this issue has been created in my GitHub fork and is available to be reviewed and to be included in the next release of the slf4j projects. The GitHub fork URL is: [https://github.com/larsmir/slf4j] The specific commit, 928ab902187ebdc78b2262214bd2cb4c36c18a9a, that makes the changes is located at: [https://github.com/larsmir/slf4j/commit/928ab902187ebdc78b2262214bd2cb4c36c…] > Thank you. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-439) OSGi dependency on CAL10N not optional
by QOS.CH (JIRA) 19 Feb '19

19 Feb '19

[ https://jira.qos.ch/browse/SLF4J-439?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-439. ------------------------------ Resolution: Fixed Fixed in [commit 603ae2cb226|https://github.com/qos-ch/slf4j/commit/603ae2cb226] > OSGi dependency on CAL10N not optional > -------------------------------------- > > Key: SLF4J-439 > URL: https://jira.qos.ch/browse/SLF4J-439 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.7.25 > Reporter: Mike Mansell > Assignee: Ceki Gülcü > Priority: Minor > Fix For: 1.8.0-beta5 > > > SLF4J-369 makes the CAL10N library optional from a Maven dependency point-of-view. However, it does not make it optional from an OSGi dependency point-of-view. The MANIFEST.MF should have a corresponding optional entry added: > {code:java} > ch.qos.cal10n;version=0.8.1;resolution:=optional{code} > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[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