[logback-dev] removing context selectors will break our libraries and applications

Garret Wilson garret at globalmentor.com
Sun Apr 28 21:50:13 CEST 2019

On 4/28/2019 12:15 PM, Ceki wrote:
> Static binding and ServiceLoader accomplish the overall same task, 
> with the ServiceLoader provide mechanism being a little more flexible.

"Little" is an understatement. :)

> The move was mandatory in order to support JPMS/Java 9 modules.

I completely understand and wholeheartedly agree. And even without Java 
9+ modules, switching to service providers is extremely welcome. The old 
approach was brittle and (etc.).

> Regarding ContextSelector, it would be possible to reintroduce it, 
> provided there is interest by the community.

Ceki, this is not just a nice-to-have; it is absolutely essential! I 
don't know how more emphatic I can be. Please see my previous email 
below. I wrote an entire DZone article discussing the need. I analyzed 
the Logback bootstrap in depth and commented on it on Stack Overflow. 
Removing the context selector functionality will completely break our 

I would imagine most in the community don't even know there exists a 
context selector, and that's mostly because using it requires setting 
some obscure properties with magic strings like "JNDI", or setting other 
properties with the name of a context selector implementation, but all 
this must be done _before the whole thing is bootstrapped_, which is 
very brittle. For example, here is how we do it, and cross our fingers 
that someone loads our class before loading the StaticLoggerBinder class:

     static {
       //tell Logback to use the ClogrContextSelector for determining 
logging contexts
       //load the SLF4J logger binder that initiates the Logback binding 
and installs the context selector

But this need not be the case! It's very simple to load the context 
selector registered as a service provider. That's why I filed 
https://jira.qos.ch/browse/LOGBACK-1196 almost three years ago. You'll 
see in the comments that another user is doing the same thing we are, 
and needs this functionality as well.

In that ticket I even provided the code you need. And it's even 

So I don't know what else to do here. I've written articles. I've posted 
on Stack Overflow. I've filed a ticket. Another user has agreed 100% 
with me. I've written the code that's needed. What else do you require?

Can I implement this for you and file a pull request somewhere?


>> On 7/6/2018 10:49 AM, Garret Wilson wrote:
>>> Hi,
>>> I've been pretty deep inside the Logback code. In fact I wrote a 
>>> comprehensive explanation on the bootstrap procedure here: 
>>> https://stackoverflow.com/a/38317149/421049
>>> We've created a library called Csar that allows one to configure 
>>> various configuration "contexts" within the same JVM, for a program 
>>> that has different locales at the same time, or different logging 
>>> configurations for different users, etc. I explain this all at 
>>> https://dzone.com/articles/creating-local-globals-with-csar .
>>> Our Clogr library used Csar to allow different logging 
>>> configurations (or even different logging libraries!) to be set up 
>>> for different parts of the application. (Imagine a server with 
>>> different user sessions, each session being logged to a different 
>>> file.) We got this working great for Logback. In fact we integrated 
>>> it into our software development course; read about it here: 
>>> https://clogr.io/learn (See the section on Clogr and 
>>> compartmentalized configurations with Logback at the bottom.)
>>> The problem is that the initial bootstrap sequence of Logback was 
>>> brittle, relying on a static class that could appear across modules. 
>>> The appearance of the Java 9+ module system prohibits this 
>>> altogether. But I had already created a ticket 
>>> https://jira.qos.ch/browse/LOGBACK-1196 for how to fix this, long 
>>> before the Java system was released, using the standard service 
>>> provider mechanism.
>>> But now I see at https://logback.qos.ch/news.html that Logback will 
>>> remove contexts altogether. This will break our ability to configure 
>>> loggers separately in our application, and to use Clogr to manage them.
>>> Why remove this? There was nothing wrong with the simple context 
>>> selection. The problem was how it was configured, using a static 
>>> classes that had to be placed in a module outside its package. Just 
>>> implement https://jira.qos.ch/browse/LOGBACK-1196, please. Don't 
>>> break our application. I even provide much of the code to do this at 
>>> LOGBACK-1196.
>>> What can we do to keep this from being removed and breaking our 
>>> library? Why do we need to remove it in the first place? Why not fix 
>>> it?
>>> (Ironically I was just told that Log4j 2 supports contexts, so maybe 
>>> our application will have to switch back to Log4j. But I would 
>>> prefer to have Clogr support both Logback and Log4j 2. There is no 
>>> reason to remove this capability from Logback.)
>>> As I mentioned two years ago in LOGBACK-1196, I'm willing to 
>>> contribute to fixing this. Let me know how to go forward.
>>> Thanks,
>>> Garret Wilson
>>> President
>>> GlobalMentor, Inc.
>>> _______________________________________________
>>> logback-dev mailing list
>>> logback-dev at qos.ch
>>> http://mailman.qos.ch/mailman/listinfo/logback-dev
>> _______________________________________________
>> logback-dev mailing list
>> logback-dev at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/logback-dev

More information about the logback-dev mailing list