java - How SLF4J-API classloading gives preference to bindings over dummy? -

if @ source code slf4j-api (any modern version, say, 1.7.5), there loggerfactory class following method:

private static set findpossiblestaticloggerbinderpathset() {     // use set instead of list in order deal  bug #138     // linkedhashset appropriate here because preserves insertion order during iteration     set staticloggerbinderpathset = new linkedhashset();     try {         classloader loggerfactoryclassloader = loggerfactory.class                 .getclassloader();         enumeration paths;         if (loggerfactoryclassloader == null) {             paths = classloader.getsystemresources(static_logger_binder_path);         } else {             paths = loggerfactoryclassloader                     .getresources(static_logger_binder_path);         }         while (paths.hasmoreelements()) {             url path = (url) paths.nextelement();             staticloggerbinderpathset.add(path);         }     } catch (ioexception ioe) {         util.report("error getting resources path", ioe);     }     return staticloggerbinderpathset; } 

this called when call logger method (debug, info, warn, error, etc.) , slf4j binding has not yet been initialized. it's how slf4j determines binding use @ runtime.

basically, 1 way write proper binding slf4j implement own org.slf4j.impl.staticloggerbinder class. however, slf4j-api jar comes it's own dummy org.slf4j.impl.staticloggerbinder implementation, prevent compiler errors during slf4j development (or act no-op fallback if no such staticloggerbinder provided binding).

hence, if have slf4j-api-1.7.5 , slf4j-simple-1.7.5 on runtime classpath, first time go use, say, logger#info(string), staticloggerbinder defined in slf4j-simple jar selected over staticloggerbinder defined in slf4j-api jar.

i'm trying understand how "preference"/prioritization (of binding impl on api impl) works. how above method first choose binding's staticloggerbinder on dummy staticloggerbinder provided in slf4j-api?

thanks in advance!

the dummy staticloggerbinder not included in slf4j-api jar file.

see pom.xml in slf4j-api source code here. dummy binder gets deleted.