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

[Garret Wilson]

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 
library.

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
       System.setProperty(LOGBACK_CONTEXT_SELECTOR, 
ClogrContextSelector.class.getName());
       //load the SLF4J logger binder that initiates the Logback binding 
and installs the context selector
       StaticLoggerBinder.getSingleton();
     }


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 
backwards-compatible!!

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?

Garret


>>
>> 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
>>
>