December 2022 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-574: slf4j OSGi metadata missing "uses" clauses
by QOS.CH (JIRA) 12 Dec '22

12 Dec '22

SLF4J / SLF4J-574 [Resolved] slf4j OSGi metadata missing "uses" clauses ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-574 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 12/Dec/22 8:21 PM Resolution: Fixed Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-575: Logback-classic 1.4.5 emits replayed events at the TRACE level
by QOS.CH (JIRA) 12 Dec '22

12 Dec '22

SLF4J / SLF4J-575 [Resolved] Logback-classic 1.4.5 emits replayed events at the TRACE level ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-575 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 12/Dec/22 8:22 PM Resolution: Fixed Status: Resolved (was: In Progress) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-575: Logback-classic 1.4.5 emits replayed events at the TRACE level
by QOS.CH (JIRA) 10 Dec '22

10 Dec '22

SLF4J / SLF4J-575 [In Progress] Logback-classic 1.4.5 emits replayed events at the TRACE level ============================== Here's what changed in this issue in the last few minutes. There are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-575 ============================== 2 comments ------------------------------ Patrick Doyle on 10/Dec/22 8:36 PM Confirmed, it works! ------------------------------ Patrick Doyle on 10/Dec/22 8:39 PM To be specific: * I built the library from that commit and arranged for it to be used in my runs * Without that library (but with logback-classic:1.4.5) I saw `TRACE`-level logging * With that library, I saw no `TRACE`-level logging, but I _did_ see logs at the `WARN` level, as expected ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-575: Logback-classic 1.4.5 emits replayed events at the TRACE level
by QOS.CH (JIRA) 10 Dec '22

10 Dec '22

SLF4J / SLF4J-575 [In Progress] Logback-classic 1.4.5 emits replayed events at the TRACE level ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-575 ============================== 1 comment ------------------------------ Ceki Gülcü on 10/Dec/22 7:32 PM Can you please test that [commit/2f4aa7|https://github.com/qos-ch/slf4j/commit/2f4aa75445116] fixes the issue? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-575: Logback-classic 1.4.5 emits replayed events at the TRACE level
by QOS.CH (JIRA) 10 Dec '22

10 Dec '22

SLF4J / SLF4J-575 [In Progress] Logback-classic 1.4.5 emits replayed events at the TRACE level ============================== Here's what changed in this issue in the last few minutes. There are 4 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-575 ============================== 4 comments ------------------------------ Ceki Gülcü on 10/Dec/22 7:08 PM The implementation of the {{Logger.log(LoggingEvent)}} method defined in {{org.slf4j.spi.LoggingEventAware}} changed between logback versions 1.2 and 1.3/1.4. The latter method implementation assumes that when the method is invoked, there was a prior definitive decision made to log the event (with no further need for filtering) whereas the prior implementation assumes that some further filtering was required. The javadoc for {{org.slf4j.spi.LoggingEventAware}} will be updated to clarify this distinction. Moreover, the {{org.slf4j.LoggerFactory#replaySingleEvent}} method will be modified to perform filtering before calling {{LoggingEventAware.log()}} which should solve the issue described here. ------------------------------ Patrick Doyle on 10/Dec/22 7:11 PM The unit test for replay doesn't test that the correct filtering hapens. https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/java… ------------------------------ Patrick Doyle on 10/Dec/22 7:14 PM Sounds great @ceki. Is there any way I can help? ------------------------------ Patrick Doyle on 10/Dec/22 7:17 PM Note to self - I see the spot where the change is required [here](https://github.com/qos-ch/slf4j/blob/363f0a534ea736bb02ced129f3ae2772…. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-575: Logback-classic 1.4.5 emits replayed events at the TRACE level
by QOS.CH (JIRA) 10 Dec '22

10 Dec '22

SLF4J / SLF4J-575 [Open] Logback-classic 1.4.5 emits replayed events at the TRACE level ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-575 ============================== Issue created ------------------------------ Patrick Doyle created this issue on 10/Dec/22 6:56 PM Summary: Logback-classic 1.4.5 emits replayed events at the TRACE level Issue Type: Bug Assignee: SLF4J developers list Components: Unspecified Created: 10/Dec/22 6:56 PM Environment: Gradle 7.4.2 running JUnit 5 tests, using slf4j-api:2.0.5 and logback-classic:1.4.5 (versions confirmed via gradle dependencies). Priority: Major Reporter: Patrick Doyle External issue URL: https://github.com/qos-ch/logback/discussions/615 Description: When I run my junit tests (in gradle, using `./gradlew test`), I see this message, followed by thousands of log messages at the `TRACE` level: SLF4J: A number (20761) of logging calls during the initialization phase have been intercepted and are SLF4J: now being replayed. These are subject to the filtering rules of the underlying logging system. However, contrary to what this says, these events do not, in fact, seem to be subject to the filtering rules. I've written a `logback-test.xml` configured as follows, which should be ignoring all `TRACE` events, and this same configuration worked as expected in logback-classic 1.2.11. ``` <configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d %-5level [%thread] %logger\{25}: %msg%n</pattern> </encoder> <immediateFlush>true</immediateFlush> </appender> <root level="WARN"> <appender-ref ref="CONSOLE" /> </root> </configuration> ``` The `appender` configuration is getting picked up correctly, which I confirmed by adding a recognizable prefix to the `pattern` tag. Also, the `appender-ref` tag is getting processed correctly, since all logs disappear if I set `ref="NONEXISTENT"`. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-574: slf4j OSGi metadata missing "uses" clauses
by QOS.CH (JIRA) 09 Dec '22

09 Dec '22

SLF4J / SLF4J-574 [Open] slf4j OSGi metadata missing "uses" clauses ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-574 ============================== 1 comment ------------------------------ Jonah Graham on 09/Dec/22 7:52 PM This is running in Eclipse, I don't really have a reduced test case. We (the Eclipse project collectively) are hitting the problem because we are trying to update to use SLF4J being [consumed directly from Maven central.|https://github.com/eclipse-platform/eclipse.platform.releng.aggreg…] Up until now we repackaged SLF4J to add the missing Uses clauses using this [bnd file|https://git.eclipse.org/r/plugins/gitiles/orbit/orbit-recipes/+/refs/h…] The problem is only exposed when there are multiple versions of SLF4J installed in the OSGi environment, without the uses clauses the OSGi wiring can cross-wire them. I don't know how to provide a reproducible test case, but I do know what needs to be changed in the manifests. The Export-Package in our rebuilt version looks like this for 1.7.30: Export-Package: org.slf4j;version="1.7.30";uses:="org.slf4j.spi", org.slf4j.event;version="1.7.30";uses:="org.slf4j,org.slf4j.helpers", org.slf4j.helpers;version="1.7.30";uses:="org.slf4j,org.slf4j.event,org.slf4j.spi", org.slf4j.spi;version="1.7.30";uses:="org.slf4j" And in the 1.7.30 on [maven central|https://central.sonatype.dev/artifact/org.slf4j/slf4j-api/1.7.30] it looks like this: Export-Package: org.slf4j;version=1.7.30, org.slf4j.spi;version=1.7.30, org.slf4j.helpers;version=1.7.30, org.slf4j.event;version=1.7.30 We haven't rebuilt the 2.x version (as we are hoping to stop doing that), but the 2.05 version looks basically the same: Export-Package: org.slf4j;version=2.0.5, org.slf4j.spi;version=2.0.5, org.slf4j.helpers;version=2.0.5, org.slf4j.event;version=2.0.5 I have provided a first stab at a fix in https://github.com/qos-ch/slf4j/pull/324 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-574: slf4j OSGi metadata missing "uses" clauses
by QOS.CH (JIRA) 09 Dec '22

09 Dec '22

SLF4J / SLF4J-574 [Open] slf4j OSGi metadata missing "uses" clauses ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-574 ============================== 1 comment ------------------------------ Ceki Gülcü on 09/Dec/22 6:59 PM [~jonahgraham] Hi Jonah, Which version of SLF4J are you using? Can you give more information about your environment. A small test project would be welcome. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-574: slf4j OSGi metadata missing "uses" clauses
by QOS.CH (JIRA) 09 Dec '22

09 Dec '22

SLF4J / SLF4J-574 [Open] slf4j OSGi metadata missing "uses" clauses ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-574 ============================== Issue created ------------------------------ Jonah Graham created this issue on 09/Dec/22 6:34 PM Summary: slf4j OSGi metadata missing "uses" clauses Issue Type: Bug Assignee: SLF4J developers list Created: 09/Dec/22 6:34 PM Environment: Running SLF4J in OSGi environment Priority: Major Reporter: Jonah Graham Description: When using SLF4J in an OSGi environment, the wiring can go wrong because SLF4J does not include uses clauses in the MANIFEST.MF. This leads to errors like: loader constraint violation: when resolving method 'org.slf4j.ILoggerFactory org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()' the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3a07fd19 of the current class, org/slf4j/LoggerFactory, and the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @773560cf for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature (org.slf4j.LoggerFactory is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3a07fd19, parent loader 'platform'; org.slf4j.impl.StaticLoggerBinder is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @773560cf, parent loader 'platform') {{}} {{}} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0