I'm updating my Clogr library to use the new SLF4J 2.x/Logback 1.4.x APIs, which (thankfully) have removed StaticLoggerBinder as I recommended above. I also see that Logback still includes ContextSelectorStaticBinder, which means it is theoretically possible to call System.setProperty(LOGBACK_CONTEXT_SELECTOR, ClogrContextSelector.class.getName()) and tell Logback to use the Clogr context selector.

But when is ContextSelectorStaticBinder.init(LoggerContext defaultLoggerContext, Object key) called in the new scheme of things? Before it was called from StaticLoggerBinder, and in fact I would do the following (hoping my class got loaded first):

static { //tell Logback to use the ClogrContextSelector for determining logging contexts
  System.setProperty(LOGBACK_CONTEXT_SELECTOR, ClogrContextSelector.class.getName());
  StaticLoggerBinder.getSingleton(); //load the SLF4J logger binder that initiates the Logback binding and installs the context selector 
}

With no StaticLoggerBinder, does that mean the SLF4J service providers will call ContextSelectorStaticBinder.init(LoggerContext defaultLoggerContext, Object key)? Or do I need to call it myself on the singleton instance?

I understand that you probably don't have time to implement a service provider framework for LoggerContext (which is the request of this ticket). But could you at least tell me how it is currently implemented in SLF4J 2.x/Logback 1.4.x? Can I get away with calling ContextSelectorStaticBinder.init(LoggerContext defaultLoggerContext, Object key) myself to set up my own logger context? Or will setting the LOGBACK_CONTEXT_SELECTOR system property early enough work? Or is LoggerContext currently even used? Thanks for any explanation.