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

[Garret Wilson]

Hi, everyone. We're really wanting to release a new version of our Clogr 
library to work with the latest Logback, but there's so much unclear 
about the current status. First, if you could be so kind as to read my 
previous email blow, which I sent almost a year ago. Now here are the 
areas I'm unclear on:

  * I had indicated that our library relies on ContextSelector. This
    class appears to be back in 1.3.0-alpha4, yet I see that
    https://logback.qos.ch/news.html still says that, "Due to lack of
    user interest, logback-classic no longer supports logging separation
    by way of ContextSelector." Is it the case that the news page is
    simply out of date and invalid?
  * As I explain in depth at https://stackoverflow.com/a/38317149/421049
    , SLF4J previous relied on StaticLoggerBinder to determine which
    SLF4J implementation would be used. The Logback implementation
    ContextSelectorStaticBinder would then determine which
    ContextSelector to use. Now that there is no StaticLoggerBinder, how
    does Logback call ContextSelectorStaticBinder.init() so that the
    default context selector will be set up?
  * In previous versions our library would call
    StaticLoggerBinder.getSingleton() to ensure that SLF4J would
    initialize the binding and set up the Logback default logger
    context. Since that is now gone, what can we call to make sure that
    SLF4J is bound to the correct implementation and the default logger
    context is available in Logback?
  * Is
    ContextSelectorStaticBinder.getSingleton().getContextSelector().getDefaultLoggerContext()
    still guaranteed to be the default logger context that was
    initialized by Logback?
  * If we switch to Logback 1.3.0-alpha4 and SLF4J 1.8.0-beta4, will all
    the other libraries that were compiled against SLF4J 1.7.25 still work?
  * Is it recommended that applications switch to Logback 1.3.0-alpha4
    and SLF4J 1.8.0-beta4, or is this just test code that is going to be
    experimented with for several years, and production code should stay
    with Logback 1.2.3 and SLFJ 1.7.25?

These are important, essential questions. Thanks in advance for 
explanations.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-dev/attachments/20190428/219480ba/attachment.html>