Hi Garret,
Off the top of my head, the migration to ServiceLoader provider
mechanism is intended to be transparent for users of the API. (On the
other hand, logging implementations , i.e. backends, need to make some
adaptations.)
Static binding and ServiceLoader accomplish the overall same task, with
the ServiceLoader provide mechanism being a little more flexible. The
move was mandatory in order to support JPMS/Java 9 modules.
Regarding ContextSelector, it would be possible to reintroduce it,
provided there is interest by the community. I guess that's the bottom line.
More inline...
--
Ceki
On 28.04.2019 16:00, Garret Wilson wrote:> 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?
The class ContextSelector might still be around but the use of
ContextSelector was commented out in LogbackServiceProvider. It would be
possible to uncomment said code without too much trouble I believe.
* 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?
As I tried to explain in the beginning of this message, the move to
ServiceLoader does not change the general mechanism.
* 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?
Loggerfactory.getProvider() ?
* Is
ContextSelectorStaticBinder.getSingleton().getContextSelector().getDefaultLoggerContext()
still guaranteed to be the default logger context that was
initialized by Logback?
ContextSelectorStaticBinder has been defanged in LogbackServiceProvider.
* 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?\
Yes.
* 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?
No, production should stay with SLF4J 1.7.25 and logback 1.2.3.
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@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
--
--
Ceki Gülcü
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
