Hi Ralph, On Thu, 18 Jan 2024 at 18:18, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Besides we already broke their code, when 2.7 introduced breaking > > changes to ConfigurationFactory. > > ? The contribution I made was done last year - long past 2.7.
Yes, what I meant is that Spring Boot uses some Log4j Core specific APIs. They are certainly aware that each major version might require a rewrite to their code. > > I am more afraid about users calling `LogManager#getContext` and other > > magical snippets of code that I don't consider being part of the > > public API (that method should have probably been protected from the > > start). > > Except tons of users call it for some reason. Yes, unfortunately. They will cry, when their code breaks and I don't have any problems in breaking such a code during a major release. I think we do not stress out enough in our documentation that a programmatic solution of a configuration problem is in 99% wrong! Unfortunately we even provide bad examples of it in our FAQ: https://logging.apache.org/log4j/3.x/faq.html#reconfig_from_code As far as the shutdown example on that page is elegant and stable, the programmatic configuration example doesn't even consider the possibility of using other logging backends. > > In 2022 we saw a lot of questions about users looking to replace > > `PropertyConfigurator` from 1.x. Unless I am mistaken, calling > > `PropertyConfigurator` was not required since Log4j 1.0. > > I am not sure what that has to do with the rest of your points. I fear our users will face the exact same problems, when migrating to Log4j Core 3.x, that they faced migrating from Log4j 1.x. Already in Log4j 1.x they had code that should never been there (Log4j 1.x looked up a `log4j.properties` file in the classpath and provided a `log4j.configuration` property from its **first** stable release). They migrated from Log4j 1.x to 2.x by just translating the same faulty code into another major version. Maybe we should have a blog post about that. Piotr
