[slf4j-dev] [JIRA] Updates for SLF4J-548: Loading services (plugins) with the caller's ClassLoader

[QOS.CH (JIRA)]

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)