<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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:</p>
<ul>
<li>I had indicated that our library relies on ContextSelector.
This class appears to be back in 1.3.0-alpha4, yet I see that
<a class="moz-txt-link-freetext" href="https://logback.qos.ch/news.html">https://logback.qos.ch/news.html</a> 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?<br>
</li>
<li>As I explain in depth at
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/a/38317149/421049">https://stackoverflow.com/a/38317149/421049</a> , 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?</li>
<li>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?<br>
</li>
<li>Is
ContextSelectorStaticBinder.getSingleton().getContextSelector().getDefaultLoggerContext()
still guaranteed to be the default logger context that was
initialized by Logback?</li>
<li>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?</li>
<li>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?</li>
</ul>
<p>These are important, essential questions. Thanks in advance for
explanations.<br>
</p>
<p>Garret<br>
</p>
<div class="moz-cite-prefix">On 7/6/2018 10:49 AM, Garret Wilson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:33ec3b5f-2e6a-df1a-a115-8e17737e8fb8@globalmentor.com">Hi,
<br>
<br>
I've been pretty deep inside the Logback code. In fact I wrote a
comprehensive explanation on the bootstrap procedure here:
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/a/38317149/421049">https://stackoverflow.com/a/38317149/421049</a>
<br>
<br>
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 <a class="moz-txt-link-freetext" href="https://dzone.com/articles/creating-local-globals-with-csar">https://dzone.com/articles/creating-local-globals-with-csar</a>
.
<br>
<br>
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: <a class="moz-txt-link-freetext" href="https://clogr.io/learn">https://clogr.io/learn</a> (See the section on Clogr and
compartmentalized configurations with Logback at the bottom.)
<br>
<br>
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
<a class="moz-txt-link-freetext" href="https://jira.qos.ch/browse/LOGBACK-1196">https://jira.qos.ch/browse/LOGBACK-1196</a> for how to fix this, long
before the Java system was released, using the standard service
provider mechanism.
<br>
<br>
But now I see at <a class="moz-txt-link-freetext" href="https://logback.qos.ch/news.html">https://logback.qos.ch/news.html</a> 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.
<br>
<br>
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 <a class="moz-txt-link-freetext" href="https://jira.qos.ch/browse/LOGBACK-1196">https://jira.qos.ch/browse/LOGBACK-1196</a>, please.
Don't break our application. I even provide much of the code to do
this at LOGBACK-1196.
<br>
<br>
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?
<br>
<br>
(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.)
<br>
<br>
As I mentioned two years ago in LOGBACK-1196, I'm willing to
contribute to fixing this. Let me know how to go forward.
<br>
<br>
Thanks,
<br>
<br>
Garret Wilson
<br>
President
<br>
GlobalMentor, Inc.
<br>
<br>
_______________________________________________
<br>
logback-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:logback-dev@qos.ch">logback-dev@qos.ch</a>
<br>
<a class="moz-txt-link-freetext" href="http://mailman.qos.ch/mailman/listinfo/logback-dev">http://mailman.qos.ch/mailman/listinfo/logback-dev</a><br>
</blockquote>
</body>
</html>