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

[JIRA] Updates for SLF4J-371: Support the lambda expression in the Logger
by QOS.CH (JIRA) 20 Nov '22

20 Nov '22

SLF4J / SLF4J-371 [Resolved] Support the lambda expression in the Logger ============================== 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-371 ============================== 1 comment ------------------------------ Ondrej Zizka on 20/Nov/22 10:23 PM Yes, using Spring Boot. In a project without Spring Boot, it was ok. But I did not go further into it yet as it works with the older. In Kotlin, one can write these 3 lines to make the evaluation lazy: {color:#002586}fun {color}{color:#000000}Logger{color}{color:#d50c0c}.{color}{color:#00627a}info{color}{color:#940076}( {color}provider: {color:#940076}() -> {color}{color:#000000}String {color}{color:#940076}) {color}{ {color:#002586}if {color}{color:#940076}({color}{color:#002586}this{color}{color:#d50c0c}.{color}{color:#871094}isInfoEnabled{color}{color:#940076}) {color}{color:#002586}this{color}{color:#d50c0c}.{color}info{color:#940076}({color}provider{color:#d50c0c}.{color}invoke{color:#940076}()) {color}} {color:#002586}fun {color}{color:#000000}Logger{color}{color:#d50c0c}.{color}{color:#00627a}debug{color}{color:#940076}( {color}provider: {color:#940076}() -> {color}{color:#000000}String {color}{color:#940076}) {color}{ {color:#002586}if {color}{color:#940076}({color}{color:#002586}this{color}{color:#d50c0c}.{color}{color:#871094}isDebugEnabled{color}{color:#940076}) {color}{color:#002586}this{color}{color:#d50c0c}.{color}debug{color:#940076}({color}provider{color:#d50c0c}.{color}invoke{color:#940076}()) {color}} {color:#002586}fun {color}{color:#000000}Logger{color}{color:#d50c0c}.{color}{color:#00627a}trace{color}{color:#940076}( {color}provider: {color:#940076}() -> {color}{color:#000000}String {color}{color:#940076}) {color}{ {color:#002586}if {color}{color:#940076}({color}{color:#002586}this{color}{color:#d50c0c}.{color}{color:#871094}isTraceEnabled{color}{color:#940076}) {color}{color:#002586}this{color}{color:#d50c0c}.{color}trace{color:#940076}({color}provider{color:#d50c0c}.{color}invoke{color:#940076}()) {color}} And then just: {code:java} log.trace { "State dump: " + expensiveLongSerialisation(state) }{code} Still, it would be nice to have that in Slf4j directly. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader
by QOS.CH (JIRA) 19 Nov '22

19 Nov '22

SLF4J / SLF4J-548 [Resolved] Loading services (plugins) with the caller's ClassLoader ============================== 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-548 ============================== 1 comment ------------------------------ Ceki Gülcü on 19/Nov/22 8:38 AM [~chadlwilson] Good to hear. Thank you for the feedback. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader
by QOS.CH (JIRA) 19 Nov '22

19 Nov '22

SLF4J / SLF4J-548 [Resolved] Loading services (plugins) with the caller's ClassLoader ============================== 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-548 ============================== 1 comment ------------------------------ Chad Wilson on 19/Nov/22 5:09 AM Thank you for addressing this in SLF4J-544 @ceki - the behaviour with 2.0.4 is much better and seems to be making the upgrade much more transparent. Have been able to get past other blocks I found after the above comments and leave things pretty much as they were with SLF4J 1.7.x which so far seems to be allowing combining different SLF4J versions across classloaders as expected and as worked earlier. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-573: SLF4J 2.0 searches for providers in the wrong classloader
by QOS.CH (JIRA) 18 Nov '22

18 Nov '22

SLF4J / SLF4J-573 [Resolved] SLF4J 2.0 searches for providers in the wrong classloader ============================== 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-573 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 18/Nov/22 10:47 AM Resolution: Done Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-573: SLF4J 2.0 searches for providers in the wrong classloader
by QOS.CH (JIRA) 18 Nov '22

18 Nov '22

SLF4J / SLF4J-573 [Open] SLF4J 2.0 searches for providers in the wrong classloader ============================== 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-573 ============================== 1 comment ------------------------------ Chris Rankin on 18/Nov/22 10:25 AM Yes, 2.0.4 works fine. Thank you. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-259: Several Type-o's in SLF4j FAQ page
by QOS.CH (JIRA) 18 Nov '22

18 Nov '22

SLF4J / SLF4J-259 [Open] Several Type-o's in SLF4j FAQ page ============================== 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-259 ============================== 1 comment ------------------------------ Michael Litwak on 18/Nov/22 8:50 AM Also, at the bottom of the SLF4J FAQ at [https://www.slf4j.org/faq.html#declaration_pattern] there are a couple places where the sample code shows: *final static Logger logger = LoggerFactory.getLogger(...* But according to [https://rules.sonarsource.com/java/tag/convention/RSPEC-1124,] the *static* keyword should come before *final*: *static final Logger logger = LoggerFactory.getLogger(...* ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-573: SLF4J 2.0 searches for providers in the wrong classloader
by QOS.CH (JIRA) 18 Nov '22

18 Nov '22

SLF4J / SLF4J-573 [Open] SLF4J 2.0 searches for providers in the wrong classloader ============================== 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-573 ============================== 1 comment ------------------------------ Ceki Gülcü on 18/Nov/22 7:36 AM [~chrisjr] Can you please try version 2.0.4 released yesterday and report back? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-573: SLF4J 2.0 searches for providers in the wrong classloader
by QOS.CH (JIRA) 18 Nov '22

18 Nov '22

SLF4J / SLF4J-573 [Open] SLF4J 2.0 searches for providers in the wrong classloader ============================== 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-573 ============================== Issue created ------------------------------ Chris Rankin created this issue on 18/Nov/22 1:18 AM Summary: SLF4J 2.0 searches for providers in the wrong classloader Issue Type: Bug Affects Versions: 2.0.3 Assignee: SLF4J developers list Components: Core API Created: 18/Nov/22 1:18 AM Environment: Java 11, Java 17 Labels: SLF4J Priority: Major Reporter: Chris Rankin Description: I have tried to upgrade my tests from SLF4J 1.7.36 to SLF4J 2.0.3, but they are failing with this error: {{java.util.ServiceConfigurationError: org.slf4j.spi.SLF4JServiceProvider: org.slf4j.simple.SimpleServiceProvider not a subtype at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1237) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265) at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300) at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385) at org.slf4j.LoggerFactory.findServiceProviders(LoggerFactory.java:104) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:147) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:139) at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:422) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:408) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383) }} My test has added slf4j-api, slf4j-simple and a jar containing a Callable into a single classloader that has a null parent classloader, and is then executing the task isolated from the application classloader. But unfortunately for me, LoggerFactory.findServiceProviders() is implemented like this: {color:#0033b3}private static {color}{color:#000000}List{color}<{color:#000000}SLF4JServiceProvider{color}> {color:#00627a}findServiceProviders{color}() { {color:#000000}ServiceLoader{color}<{color:#000000}SLF4JServiceProvider{color}> {color:#000000}serviceLoader {color}= {color:#000000}ServiceLoader{color}.load({color:#000000}SLF4JServiceProvider{color}.{color:#0033b3}class{color}); {color:#000000}List{color}<{color:#000000}SLF4JServiceProvider{color}> {color:#000000}providerList {color}= {color:#0033b3}new {color}ArrayList<>(); {color:#0033b3}for {color}({color:#000000}SLF4JServiceProvider provider {color}: {color:#000000}serviceLoader{color}) { {color:#000000}providerList{color}.add({color:#000000}provider{color}); } {color:#0033b3}return {color}{color:#000000}providerList{color}; } Specifically, ServiceLoader.load() does not specify which classloader to use, and so defaults to the ThreadContextClassLoader. I believe a more compatible (with earlier versions of SLF4J) choice would be: {color:#000000}ServiceLoader{color}.load({color:#000000}SLF4JServiceProvider{color}.{color:#0033b3}class, LoggerFactory.class.getClassLoader(){color}) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-544: LoggerFactory only loads services from context class loader
by QOS.CH (JIRA) 18 Nov '22

18 Nov '22

SLF4J / SLF4J-544 [Resolved] LoggerFactory only loads services from context class loader ============================== 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-544 ============================== 1 comment ------------------------------ Ceki Gülcü on 18/Nov/22 1:00 AM [~rgoers(a)apache.org] The naive solution can be sufficient. I think it is worthwhile to try something very simple, which incidentally also matches the behavior of the 1.7 series. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-544: LoggerFactory only loads services from context class loader
by QOS.CH (JIRA) 17 Nov '22

17 Nov '22

SLF4J / SLF4J-544 [Resolved] LoggerFactory only loads services from context class loader ============================== 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-544 ============================== 1 comment ------------------------------ Ralph Goers on 17/Nov/22 11:28 PM I just have to say that in some cases this fix will still be insufficient. Presumably the caller of LoggerFactory could be the application. But if the SLF4J implementation isn't included in the application classloader then locating it could still fail. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0