> On Jan 18, 2024, at 12:59 PM, Piotr P. Karwasz <piotr.karw...@gmail.com>
> wrote:
>
> 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.
That is what I am saying. Since I wrote the code they most certainly expect it
won’t change.
>
>>> 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 do. Primarily becase it could be happening in some random library they have
no control over.
>
> 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
None of us have ever been happy about programmatic configuration and we have
gone out of our way to make it unnecessary. But users still do it. Some even
have valid reasons. I am sure Spring does it to some degree,
>
> 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.
Yes, I am aware that users frequently just want to make something they have
work even though we provided better ways.
>
> Maybe we should have a blog post about that.
I doubt most of the users who are doing this would read it.
Ralph
