- slf4j-dev - mailman3.qos.ch

test
by slf4j developers list 16 Jun '25

16 Jun '25

Testing please ignore. -- Ceki Gülcü

1 0

More variable parameters than placeholders, some parameters not logged
by slf4j developers list 26 Jan '25

26 Jan '25

With this method or any similar method, public void info(String format, Object... arguments) { if (isInfoEnabled()) { handleArgArrayCall(Level.INFO, null, format, arguments); } }If the number of objects in 'arguments' is more than the number of placeholders, {}, the extra argument objects are not logged. Is there a reason for that? For example public void setTemperature(Integer temperature) { oldT = t; t = temperature; //Sent three parameters log with two placeholders //Output "Temperature set to 90. Old value was null." The word extra is not printed logger.info("Temperature set to {}. Old value was {}.", t, oldT, "extra"); if(temperature.intValue() > 50) { logger.info("Temperature has risen above 50 degrees."); } } If I get into a situation where I have sent more argument objects than placeholders that it should append those un-placed arguments to the end of the logged string. The intent of the developer is to have the parameter logged. Finding this out from production is not good. What is sent to be logged is important information, depending on the log level. My use case is that I want to push some legacy code to start looking like SLF4J so we can migrate away from the older pattern filled with isLogTraceEnabled calls. I learned of the above when I was writing JUnit tests to see all the things the code would do and not do. I feel that https://www.slf4j.org/faq.html#logging_performance is telling me that, in some way, the placeholder string substitution is faster than appending multiple strings together. I understood the main point of the argument as converting items to string before I needed them was where the overhead was. Keeping them as type Object reduces that overhead. I understand there are Sonarqube rules and PMD to prevent me from not having the correct number of argument objects. This would help, but I feel like there are still going to be misses. Since my code is custom, Sonarqube and PMD do not feel like options.

1 1

[JIRA] Updates for SLF4J-604: slf4j-jdk14 adapter: Logger.log's fqcn parameter ignored #425
by slf4j developers list 21 Oct '24

21 Oct '24

SLF4J / SLF4J-604 [Resolved] slf4j-jdk14 adapter: Logger.log's fqcn parameter ignored #425 ============================== 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-604 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 21/Oct/24 19:03 Resolution: Fixed Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-604: slf4j-jdk14 adapter: Logger.log's fqcn parameter ignored #425
by slf4j developers list 28 Aug '24

28 Aug '24

SLF4J / SLF4J-604 [Open] slf4j-jdk14 adapter: Logger.log's fqcn parameter ignored #425 ============================== 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-604 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 28/Aug/24 8:33 Summary: slf4j-jdk14 adapter: Logger.log's fqcn parameter ignored #425 Issue Type: Bug Affects Versions: 2.0.13 Assignee: SLF4J developers list Components: Core API Created: 28/Aug/24 8:33 Fix Versions: 2.0.14 Priority: Major Reporter: Ceki Gülcü Description: See https://github.com/qos-ch/slf4j/issues/425 ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-603: Purpose of SLF4JServiceProvider.getRequestedApiVersion()
by slf4j developers list 14 Jun '24

14 Jun '24

SLF4J / SLF4J-603 [Open] Purpose of SLF4JServiceProvider.getRequestedApiVersion() ============================== 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-603 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 14/Jun/24 15:54 Summary: Purpose of SLF4JServiceProvider.getRequestedApiVersion() Issue Type: Task Assignee: SLF4J developers list Components: Implementations Created: 14/Jun/24 15:54 Fix Versions: 2.0.14 Priority: Major Reporter: Ceki Gülcü Description: https://github.com/qos-ch/slf4j/discussions/363 ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-602: JCL-Over-SLF4J Module Definition does not specify the service loader (Issue #414)
by slf4j developers list 14 Apr '24

14 Apr '24

SLF4J / SLF4J-602 [Open] JCL-Over-SLF4J Module Definition does not specify the service loader (Issue #414) ============================== 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-602 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 14/Apr/24 9:54 Summary: JCL-Over-SLF4J Module Definition does not specify the service loader (Issue #414) Issue Type: Bug Assignee: SLF4J developers list Created: 14/Apr/24 9:54 Priority: Major Reporter: Ceki Gülcü External issue URL: https://github.com/qos-ch/slf4j/issues/414 Description: Guys, The module definition for the jcl-over-slf4j unfortunately does not specify the service loader for org.apache.commons.logging.LogFactory When executing applications in a built JRE (Using JLink or JPackage), the services are loaded from their module definitions, and the functionality is not loaded. Could you please possible update the module definition - `module org.apache.commons.logging { requires org.slf4j; exports org.apache.commons.logging; provides org.apache.commons.logging.LogFactory with org.apache.commons.logging.impl.SLF4JLogFactory; } ` Much appreciated ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-601: Wrong class name printed when using LoggingEventBuilder with payload #416
by slf4j developers list 09 Apr '24

09 Apr '24

SLF4J / SLF4J-601 [Open] Wrong class name printed when using LoggingEventBuilder with payload #416 ============================== 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-601 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 09/Apr/24 5:50 Summary: Wrong class name printed when using LoggingEventBuilder with payload #416 Issue Type: Bug Assignee: SLF4J developers list Created: 09/Apr/24 5:50 Priority: Major Reporter: Ceki Gülcü Description: The wrong class name is printed when using the LoggingEventBuilder with a payload. The following example demonstrates the issue: package my.pkg import io.github.oshai.kotlinlogging.KotlinLogging private val logger = KotlinLogging.logger { } fun main() { logger.atInfo { message = "hi" payload = mapOf("k" to "v") } logger.atInfo { message = "hi" } } Which will print: Apr. 06, 2024 4:49:02 AM io.github.oshai.kotlinlogging.slf4j.internal.LocationAwareKLogger logWithPayload INFORMATION: k=v hi Apr. 06, 2024 4:49:02 AM my.pkg.MyClassKt main INFORMATION: hi The first log statement will be logged with io.github.oshai.kotlinlogging.slf4j.internal.LocationAwareKLogger as a classname. Which is wrong. It supposed to be my.pkg.MyClassKt. In the second log statement however it seems to work fine. Check out the example to reproduce the issue: example.zip ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 06 Nov '23

06 Nov '23

SLF4J / SLF4J-592 [Resolved] Mechanism for indicating provider to use for unit tests. ============================== 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-592 ============================== 1 comment ------------------------------ Garret Wilson on 06/Nov/23 21:49 As of [JAVA-356|https://globalmentor.atlassian.net/browse/JAVA-356] I've removed {{slf4j-simple}} from the root POM so that it won't be added to the test scope anymore, and as of [CLOGR-14|https://globalmentor.atlassian.net/browse/CLOGR-14] the next version of Clogr will allow me to do the following in any unit tests to suppress logging output altogether (so that they don't add junk to Maven builds, for example). {code:java} @BeforeAll static void suppressLogging() { setSystemDefaultLoggingProviderNop(); } {code} This will do for now to clean up the build output. Once [#361|https://github.com/qos-ch/slf4j/issues/361] is addressed to disable the extra , I'll use SLF4J-450 to turn off logging in the Maven build altogether [using Surefire|https://maven.apache.org/surefire/maven-surefire-plugin/examples/s…] as discussed in this ticket. Then I'll add a simple {{stderr}} provider that doesn't advertise itself to SLF4J, but that I can still programmatically select in the unit tests, so that with SLF4J-450 I can then still run the test in the IDE and see output in {{stderr}}, but have Maven Surefire set {{slf4j.provider}} to the NOP provider so that the full build doesn't show anything. I guess the only thing preventing me from doing this last part already is that {{slf4j-simple}} advertises itself as a provider just by including it. It would be nice if there were two separate libraries, one for {{slf4j-simple}} and the other for {{slf4j-simple-provider}}. But no worries—I can write my own. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 06 Nov '23

06 Nov '23

SLF4J / SLF4J-592 [Resolved] Mechanism for indicating provider to use for unit tests. ============================== 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-592 ============================== 1 comment ------------------------------ Garret Wilson on 06/Nov/23 19:53 [~ceki] I want to say thanks for the discussion here on how to have different logging implementations for unit tests. You've marked this ticket as a duplicate of SLF4J-450. That's fine, although I would say that SLF4J-450 is one possible way to address this larger issue. In fact I want to step back and reevaluate what I was trying to do in the beginning and give a summary for the record. I opened this ticket because I wanted to see any log output of my unit tests to {{stdout}}. At least I thought I did. But upon reflection I don't want to see all that logging stuff in the output of my Maven build. what I _really_ want is to _disable_ the logging for unit tests, but somehow easily turn them on arbitrarily when I'm debugging my unit tests. Disabling the output is easy—sort of: I can just do nothing, and SLF4J will fall back to a NOP provider, but it will still show some ugly logging. It turns out I can play some tricks with SLF4J-450 to get around that. And to arbitrarily turn on logging to {{stdout}}, again I can play some tricks with SLF4J-450. So in the end I think {{SLF4J-450}} will allow me to do what I (discovered that I really) want to do, and I'll wind up taking {{slf4j-simple}} out of my root POM altogether. I'm going to implement this in my [Clogr](https://clogr.io/) library. I'll come back and add one more update here to explain how it all fits together. Note that ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests
by slf4j developers list 06 Oct '23

06 Oct '23

SLF4J / SLF4J-579 [Reopened] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== 1 comment ------------------------------ Konrad Windszus on 06/Oct/23 14:35 I now raised https://github.com/qos-ch/slf4j/pull/358 to export both org.slf4j and org.slf4j.helper in the backwards compatible version 1.8.0 (in addition to the default version = bundle version). Also this PR enforces semantical versioning with https://felix.apache.org/documentation/_attachments/components/bundle-plugi… (as the maven-bundle-plugin is already used for generating the MANIFEST.MF). ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0