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
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
