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

[Garret Wilson]

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.