removing context selectors will break our libraries and applications
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.
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@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
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ü
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@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
participants (2)
-
Ceki -
Garret Wilson