[slf4j-dev] [JIRA] Updates for SLF4J-573: SLF4J 2.0 searches for providers in the wrong classloader

[QOS.CH (JIRA)]

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)