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

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

03 Sep '22

SLF4J / SLF4J-548 [Open] 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 03/Sep/22 10:06 AM Yeah, it's probably not 100% the same as yours (I am still figuring out a full fix/workaround in my case in cases where I have both Logback 1.2 and Logback 1.4 loaded in different classloaders in the same VM, but I concluded it also relates to possible downstream problems caused by the ServiceLoader change in situations where logback is being loaded in different classloader configurations, and since there was some discussion above referring back to all the old challenges with JCL and parent-first and child-first class loaders, it seemed relevant. It's maybe worth noting that the way the ServiceLoader is used in logback *1.2.x* for finding its Configurator is a bit inconsistent with the new SLF4J 1.8+ approach (for whatever reason), instead using the classloader of the caller rather than solely relying on the TCCL: *ContextInitializer.autoConfig()* https://github.com/qos-ch/logback/blob/ca0cf172f680308938515b8a5d69348759ee… *EnvUtil.loadFromServiceLoader(clazz)* https://github.com/qos-ch/logback/blob/ca0cf172f680308938515b8a5d69348759ee… ============================== 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) 02 Sep '22

02 Sep '22

SLF4J / SLF4J-548 [Open] 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 ------------------------------ Piotr P. Karwasz on 02/Sep/22 11:30 PM [~ceki], I also believe that calling {{ServiceLoader.load}} without a classloader parameter is a bug: if SLF4J is in the common classloader of a servlet container, it can unintentionally bind with a service provider in a webapp classloader. This will cause a memory leak whenever the application is undeployed (and a broken logging system). I submitted [PR #304|https://github.com/qos-ch/slf4j/pull/304] to solve this and two other {{ServiceLoader}} problems. It should also solve [~chadlwilson]'s problem, which manifests when a copy of SLF4J bundled with a webapp tries to load service providers in its parent classloader. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-557: MDCCloseable: not a great fit for a try-with-resources statement
by QOS.CH (JIRA) 02 Sep '22

02 Sep '22

SLF4J / SLF4J-557 [Open] MDCCloseable: not a great fit for a try-with-resources statement ============================== 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-557 ============================== Issue created ------------------------------ Alberto Scotto created this issue on 02/Sep/22 11:05 PM Summary: MDCCloseable: not a great fit for a try-with-resources statement Issue Type: Bug Assignee: SLF4J developers list Components: Core API Created: 02/Sep/22 11:05 PM Labels: MDC Priority: Major Reporter: Alberto Scotto Description: Although the idea of the MDCCloseable is really nice, because it makes for some quite neat code (and I like 'neat' a lot), unfortunately there are some design drawbacks which make it a bad idea. Let me start with an example. {code:java} try (MDCCloseable ignored = MDC.putCloseable("k", "v")) { // body } catch (Exception e) { log.error("An error occurred", e); }{code} If an exception is thrown, would you expect the log statement to include the (k ,v) pair in the MDC or not? Or, put in another way, would you _like_ the log statement to include the (k ,v) pair in the MDC? I definitely would. The reason is that in general I would expect a try-with-resources statement to execute the close() as the very last thing, _after_ the catch block was executed. In other words, I would expect a try-with-resources statement to behave just like a plain old try/catch/finally statement: {code:java} MDCCloseable mdcCloseable = MDC.putCloseable("k", "v"); try { // body } catch (Exception e) { log.error("An error occurred", e); } finally { mdcCloseable.close(); }{code} But, as it turns out, this is not the case. As it's well explained [here|https://stackoverflow.com/questions/32849066/java-try-with-resources-v…] when a try-with-resources statement has a catch block, the catch block is executed _before_ the implicit finally, i.e. the close(). While for a resource like a handle to a file or a socket it's irrelevant whether the resource is closed before or after the catch block, for a MDCCloseable it does matter a lot. Because, as we can see in the example, if we have a log statement in the catch block, and the MDCCloseable defined an important piece of information (say the ID of an entity which was being processed in the try block), closing the resource before the catch block means that our log statement will be missing that piece of information. So every time we need to define a catch block along with the try-with-resources holding our MDCCloseable, we actually need to throw away the try-with-resources, and write a plain old try/catch/finally: {code:java} MDCCloseable mdcCloseable = MDC.putCloseable("k", "v") try { // body } catch (Exception e) { log.error("An error occurred", e); } finally { mdcCloseable.close(); // in this form, if body throws an exception, close() is executed _after_ the log statement }{code} What about those try-with-resources statements where we don't have a catch block? Well _at the minute_ we don't, but we might in the future, and if that happens there's a chance we might forget to switch to a plain old try/catch/finally, therefore missing some pieces of information in the logs. For this reason I would like to ask to throw away the MDCCloseable completely, by starting deprecating the method `MDC#putCloseable`. ============================== 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) 02 Sep '22

02 Sep '22

SLF4J / SLF4J-548 [Open] 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 ------------------------------ pierre on 02/Sep/22 4:53 PM Hi Chad Wilson, I'm not sure your problem is related to mine. But you can try with this modified [slf4j-api.jar archive|https://github.com/prrvchr/jdbcDriverOOo/raw/master/source/UnoLogge…] which loads the services with the class loader of the caller. If it works then your problem is there... ============================== 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) 02 Sep '22

02 Sep '22

SLF4J / SLF4J-548 [Open] 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 02/Sep/22 4:26 PM I'm not sure I really understand why as I am also not a ClassLoader god, but with the new *ServiceLoader* mechanism in 2.0.0 I am back into classloader hell within [https://github.com/gocd/gocd] which also does "plugin-like" things, such as dynamically downloading a JAR file and then booting that in a *URLClassLoader*. Presumably these issues are due to the exclusive use of the TCCL in the ServiceLoader call. There is some legacy classloader stuff GoCD does that I don't really understand, but what previously worked with the StaticLoggerBinder now seems to confuse Slf4j and we end up with {noformat} Caused by: java.util.ServiceConfigurationError: org.slf4j.spi.SLF4JServiceProvider: ch.qos.logback.classic.spi.LogbackServiceProvider not a subtype at java.base/java.util.ServiceLoader.fail(Unknown Source) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown Source) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown Source) at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source) at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source) 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:421) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:407) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:356) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:382){noformat} which seems basically like the Type II classloader problems of old JCL-land. Applying the workaround suggested above in just the right place to set the TCCL to *LoggerFactory.class.getClassLoader()* around the *LoggerFactory.getLogger()* call seems to work, but feels extremely brittle. Seems also related to SLF4J-544 and SLFJ-227 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0