Re: [log4j] Making Log4j 2 API "the Log4j API"

[Volkan Yazıcı]

If we

   1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
   in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
   2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!)
   in `log4j-core`

we can have a Log4j 3 without a `log4j-api-3.x` module, right?

> We would need to compare the two branches of log4j-api
> and see what the differences are.

#2208  synchronizes
`log4j-api` between `2.x` and `main`. Hence, I presume the answer to your
question is "none", except the minor intentional differences shared in the
PR description.

> Doesn’t that mean users would now need log4j-api-2.x.jar
> and log4j-spi-3,x,jar?

No. `log4j-spi-3.x` will be used by `log4j-core`, `log4j-slf4j2-impl`, etc.
Library authors who only code against the API or users who convert
everything to SLF4J via `log4j-to-slf4j` will only need `log4j-api-2.x`.


On Thu, Jan 18, 2024 at 6:13 AM Ralph Goers 
wrote:

> Now that I have had 10 seconds to think about it.  The change to the
> property syntax and how PropertiesUtil works will create serious problems
> for what you are proposing.
>
> Ralph
>
> > On Jan 17, 2024, at 10:02 PM, Ralph Goers 
> wrote:
> >
> > The quick answer to this question is “I don’t know”. When we first
> started on the 3.x adventure I can assure you that log4j-api was very
> different in the 3.x branch because of the changes we needed to make for
> JPMS and to the build. However, since we have since carried those changes
> back to 2.x to a large degree it may be that you are correct and we don’t
> need to create a 3.x version of the API.
> >
> > We would need to compare the two branches of log4j-api and see what the
> differences are.
> >
> > Ralph
> >
> >> On Jan 17, 2024, at 9:11 AM, Volkan Yazıcı  wrote:
> >>
> >> Given Ralph and Piotr are strongly opinionated about keeping
> >> `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release
> >> `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x`
> >> instead? (We can move the contents of the `spi` package in
> `log4j-api-3.x`
> >> to a separate `log4j-spi` module in `main`.) This will make everything
> >> crystal clear:
> >>
> >>  - Log4j 3 is just a major improvement over the backend
> >>  - Log4j 3 still supports Log4j 2 API
> >>  - We can move the Log4j 2 API to a separate repository with its own
> >>  release life cycle (ala SLF4J)
> >>  - When time comes to make a new Log4j API where PMC agrees to make
> >>  breaking changes, we can call that one Log4j 3 API
> >>
> >> I would appreciate it if you can help me to understand if I am
> >> missing something. Otherwise, I would like to know why we need to make a
> >> major release for a project that is identical to its previous version.
> >
>
>

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Gary Gregory]

Using the same API jar for 3.x core is intriguing. I like the idea of
a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x.

I'd love to hash this out in a call.

Gary

On Thu, Jan 18, 2024 at 12:02 AM Ralph Goers  wrote:
>
> The quick answer to this question is “I don’t know”. When we first started on 
> the 3.x adventure I can assure you that log4j-api was very different in the 
> 3.x branch because of the changes we needed to make for JPMS and to the 
> build. However, since we have since carried those changes back to 2.x to a 
> large degree it may be that you are correct and we don’t need to create a 3.x 
> version of the API.
>
> We would need to compare the two branches of log4j-api and see what the 
> differences are.
>
> Ralph
>
> > On Jan 17, 2024, at 9:11 AM, Volkan Yazıcı  wrote:
> >
> > Given Ralph and Piotr are strongly opinionated about keeping
> > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release
> > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x`
> > instead? (We can move the contents of the `spi` package in `log4j-api-3.x`
> > to a separate `log4j-spi` module in `main`.) This will make everything
> > crystal clear:
> >
> >   - Log4j 3 is just a major improvement over the backend
> >   - Log4j 3 still supports Log4j 2 API
> >   - We can move the Log4j 2 API to a separate repository with its own
> >   release life cycle (ala SLF4J)
> >   - When time comes to make a new Log4j API where PMC agrees to make
> >   breaking changes, we can call that one Log4j 3 API
> >
> > I would appreciate it if you can help me to understand if I am
> > missing something. Otherwise, I would like to know why we need to make a
> > major release for a project that is identical to its previous version.
>

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

> On Jan 18, 2024, at 6:15 AM, Gary Gregory  wrote:
> 
> Using the same API jar for 3.x core is intriguing. I like the idea of
> a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x.
> 

I don’t think that is what Volkan is proposing as it definitely would break 
compatibility between 2.x versions of the API.

Ralph

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı  wrote:
> 
> If we
> 
>   1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
>   in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
>   2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!)
>   in `log4j-core`
> 
> we can have a Log4j 3 without a `log4j-api-3.x` module, right?

Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean anything 
impacted by the property changes would have to be in the spi or abstracted to 
reference something in the spi. I am assuming a log4j-spi-2.x would also be 
needed. There are many other utility classes that have never been off limits 
for users to use.

While your idea could work it definitely would impact some users.

Ralph

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

> On Jan 18, 2024, at 7:55 AM, Ralph Goers  wrote:
> 
> 
> 
>> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı  wrote:
>> 
>> If we
>> 
>>  1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
>>  in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
>>  2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!)
>>  in `log4j-core`
>> 
>> we can have a Log4j 3 without a `log4j-api-3.x` module, right?
> 
> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean 
> anything impacted by the property changes would have to be in the spi or 
> abstracted to reference something in the spi. I am assuming a log4j-spi-2.x 
> would also be needed. There are many other utility classes that have never 
> been off limits for users to use.
> 
> While your idea could work it definitely would impact some users.


Note that LogManager has

import org.apache.logging.log4j.simple.SimpleLoggerContextFactory;
import org.apache.logging.log4j.spi.LoggerContext;
import org.apache.logging.log4j.spi.LoggerContextFactory;
import org.apache.logging.log4j.spi.LoggingSystem;
import org.apache.logging.log4j.spi.Terminable;
import org.apache.logging.log4j.status.StatusLogger;
import org.apache.logging.log4j.util.StackLocatorUtil;
import org.apache.logging.log4j.util.Strings;

That would require users to have the SPI would it not?

Ralph

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

> On Jan 18, 2024, at 8:14 AM, Ralph Goers  wrote:
> 
> 
> 
>> On Jan 18, 2024, at 7:55 AM, Ralph Goers  wrote:
>> 
>> 
>> 
>>> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı  wrote:
>>> 
>>> If we
>>> 
>>> 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes
>>> in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and
>>> 2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!)
>>> in `log4j-core`
>>> 
>>> we can have a Log4j 3 without a `log4j-api-3.x` module, right?
>> 
>> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean 
>> anything impacted by the property changes would have to be in the spi or 
>> abstracted to reference something in the spi. I am assuming a log4j-spi-2.x 
>> would also be needed. There are many other utility classes that have never 
>> been off limits for users to use.
>> 
>> While your idea could work it definitely would impact some users.
> 
> 
> Note that LogManager has
> 
> import org.apache.logging.log4j.simple.SimpleLoggerContextFactory;
> import org.apache.logging.log4j.spi.LoggerContext;
> import org.apache.logging.log4j.spi.LoggerContextFactory;
> import org.apache.logging.log4j.spi.LoggingSystem;
> import org.apache.logging.log4j.spi.Terminable;
> import org.apache.logging.log4j.status.StatusLogger;
> import org.apache.logging.log4j.util.StackLocatorUtil;
> import org.apache.logging.log4j.util.Strings;
> 
> That would require users to have the SPI would it not?

And ThreadContext contains

import org.apache.logging.log4j.message.ParameterizedMessage;
import org.apache.logging.log4j.spi.LoggingSystem;
import org.apache.logging.log4j.spi.LoggingSystemProperty;
import org.apache.logging.log4j.spi.ReadOnlyThreadContextMap;
import org.apache.logging.log4j.spi.ThreadContextMap;
import org.apache.logging.log4j.spi.ThreadContextStack;
import org.apache.logging.log4j.util.InternalApi;
import org.apache.logging.log4j.util.Strings;


I actually think your idea of splitting the API into API and SPI makes sense 
but it doesn’t seem like it is going to be all that simple to do.  The API will 
have to only reference interfaces that are in the api and the spi would 
implement them. I don’t know if that can be done without impacting users.

Ralph

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Piotr P. Karwasz]

Hi Volkan,

On Wed, 17 Jan 2024 at 17:12, Volkan Yazıcı  wrote:
> Given Ralph and Piotr are strongly opinionated about keeping
> `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release
> `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x`
> instead?

The main problem with breaking the compatibility of `log4j-api` is that:
 * a logging API is used by virtually every other library,
 * we are at the bottom of the food chain

If we have breaking changes, an application that wants to migrate to
Log4j 3.x API will have to wait for **all** its dependencies to
migrate to Log4j 3.x API.
For a library to migrate to Log4j 3.x API will mean they need to start
a new minor release that will only be used by applications, when other
libraries do the same.
Nobody is going to do this for a glorified System.out.println library.

Remark that Gary also does not advocate for breaking changes in
`o.a.l.l`, but he proposes to create a new package. This is
technically **not** a breaking change.
I am also not a big fan of this solution because it gives users **no**
incentive to migrate to Log4j 3.x API. They will just accumulate
several Log4j APIs in their applications as they do with Commons Lang
or HttpComponents.

The morale is that we should **never** break `log4j-api`.

There is some middle ground to these extreme solutions:

 * we can create a new `v3` package and let the v2 interfaces extend
those from v3 (proof-of-concept in PR#2215),
 * we could make breaking changes and instruct users to add
`log4j-api` to the "provided" scope. At runtime `log4j-core` will
depend on an "enhanced" version of `log4j-api` (let's call it
`log4j-api-legacy`) that will have **all** the methods we removed from
`log4j-api` and hence will be backward compatible with v2.

> This will make everything
> crystal clear:
>
>- Log4j 3 is just a major improvement over the backend
>- Log4j 3 still supports Log4j 2 API
>- We can move the Log4j 2 API to a separate repository with its own
>release life cycle (ala SLF4J)
>- When time comes to make a new Log4j API where PMC agrees to make
>breaking changes, we can call that one Log4j 3 API

Sounds good to me. We can mark as deprecated in 2.x all the classes
from `log4j-api` that we consider either part of the SPI or totally
internal to the project.

Piotr

[1] https://github.com/apache/logging-log4j2/pull/2215

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Piotr P. Karwasz]

Hi Ralph,

On Thu, 18 Jan 2024 at 15:56, Ralph Goers  wrote:
> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean 
> anything impacted by the property changes would have to be in the spi or 
> abstracted to reference something in the spi. I am assuming a log4j-spi-2.x 
> would also be needed. There are many other utility classes that have never 
> been off limits for users to use.
>
> While your idea could work it definitely would impact some users.

Spring Boot contributors were probably aware that `PropertiesUtil` is
not part of the public API. ;-)
Besides we already broke their code, when 2.7 introduced breaking
changes to ConfigurationFactory.
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).

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.

Piotr

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Piotr P. Karwasz]

Hi Ralph,

On Thu, 18 Jan 2024 at 16:15, Ralph Goers  wrote:
> Note that LogManager has
>
> import org.apache.logging.log4j.simple.SimpleLoggerContextFactory;
> import org.apache.logging.log4j.spi.LoggerContext;
> import org.apache.logging.log4j.spi.LoggerContextFactory;
> import org.apache.logging.log4j.spi.LoggingSystem;
> import org.apache.logging.log4j.spi.Terminable;
> import org.apache.logging.log4j.status.StatusLogger;
> import org.apache.logging.log4j.util.StackLocatorUtil;
> import org.apache.logging.log4j.util.Strings;
>
> That would require users to have the SPI would it not?

On Thu, 18 Jan 2024 at 16:20, Ralph Goers  wrote:
> And ThreadContext contains
>
> import org.apache.logging.log4j.message.ParameterizedMessage;
> import org.apache.logging.log4j.spi.LoggingSystem;
> import org.apache.logging.log4j.spi.LoggingSystemProperty;
> import org.apache.logging.log4j.spi.ReadOnlyThreadContextMap;
> import org.apache.logging.log4j.spi.ThreadContextMap;
> import org.apache.logging.log4j.spi.ThreadContextStack;
> import org.apache.logging.log4j.util.InternalApi;
> import org.apache.logging.log4j.util.Strings

IMHO, the public API contains:

1. all the types in the `o.a.l.l` package,
2. all the superclasses and superinterfaces of a type in the public
API (recursively),
3. all the types that appear in the signature of public methods of a
type in the public API (recursively).

Which mean the the Log4j API contains `o.a.l.l` and the following
types from other packages:

org.apache.logging.log4j.message.EntryMessage
org.apache.logging.log4j.message.ExitMessage
org.apache.logging.log4j.message.FlowMessage
org.apache.logging.log4j.message.FlowMessageFactory
org.apache.logging.log4j.message.Message
org.apache.logging.log4j.message.MessageFactory
org.apache.logging.log4j.spi.LoggerContext
org.apache.logging.log4j.spi.ExtendedLogger
org.apache.logging.log4j.spi.LoggerContextFactory
org.apache.logging.log4j.spi.LoggerRegistry
org.apache.logging.log4j.spi.StandardLevel
org.apache.logging.log4j.spi.ReadOnlyThreadContextMap
org.apache.logging.log4j.util.BiConsumer
org.apache.logging.log4j.util.ReadOnlyStringMap
org.apache.logging.log4j.util.StringMap
org.apache.logging.log4j.util.StringBuilderFormattable
org.apache.logging.log4j.util.Supplier
org.apache.logging.log4j.util.TriConsumer

Removing a method from any one of these can break user's code. Some of
these (certainly `Supplier`, but to a smaller extent `Message`,
`BiConsumer` and `TriConsumer`) are implemented by users, so even
adding an abstract method to those, will break user code.

Piotr

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

> On Jan 18, 2024, at 9:01 AM, Piotr P. Karwasz  wrote:
> 
> Hi Ralph,
> 
> On Thu, 18 Jan 2024 at 15:56, Ralph Goers  wrote:
>> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean 
>> anything impacted by the property changes would have to be in the spi or 
>> abstracted to reference something in the spi. I am assuming a log4j-spi-2.x 
>> would also be needed. There are many other utility classes that have never 
>> been off limits for users to use.
>> 
>> While your idea could work it definitely would impact some users.
> 
> Spring Boot contributors were probably aware that `PropertiesUtil` is
> not part of the public API. ;-)

Well, I contributed the PR and have always assumed PropertiesUtil was public. 
They modified my PR to limit the scope of the PropertySource but not much more 
than that.


> 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.

> 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.

> 
> 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.

Ralph

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

I have a much more liberal view of the API. That is, if the class isn’t 
documented as private AND it can be reasonably used outside of Log4j then it is 
public.  However, I would actually have to look at every class to see how much 
different it is from your list.

Ralph


> On Jan 18, 2024, at 9:25 AM, Piotr P. Karwasz  wrote:
> 
> Hi Ralph,
> 
> On Thu, 18 Jan 2024 at 16:15, Ralph Goers  wrote:
>> Note that LogManager has
>> 
>> import org.apache.logging.log4j.simple.SimpleLoggerContextFactory;
>> import org.apache.logging.log4j.spi.LoggerContext;
>> import org.apache.logging.log4j.spi.LoggerContextFactory;
>> import org.apache.logging.log4j.spi.LoggingSystem;
>> import org.apache.logging.log4j.spi.Terminable;
>> import org.apache.logging.log4j.status.StatusLogger;
>> import org.apache.logging.log4j.util.StackLocatorUtil;
>> import org.apache.logging.log4j.util.Strings;
>> 
>> That would require users to have the SPI would it not?
> 
> On Thu, 18 Jan 2024 at 16:20, Ralph Goers  wrote:
>> And ThreadContext contains
>> 
>> import org.apache.logging.log4j.message.ParameterizedMessage;
>> import org.apache.logging.log4j.spi.LoggingSystem;
>> import org.apache.logging.log4j.spi.LoggingSystemProperty;
>> import org.apache.logging.log4j.spi.ReadOnlyThreadContextMap;
>> import org.apache.logging.log4j.spi.ThreadContextMap;
>> import org.apache.logging.log4j.spi.ThreadContextStack;
>> import org.apache.logging.log4j.util.InternalApi;
>> import org.apache.logging.log4j.util.Strings
> 
> IMHO, the public API contains:
> 
> 1. all the types in the `o.a.l.l` package,
> 2. all the superclasses and superinterfaces of a type in the public
> API (recursively),
> 3. all the types that appear in the signature of public methods of a
> type in the public API (recursively).
> 
> Which mean the the Log4j API contains `o.a.l.l` and the following
> types from other packages:
> 
> org.apache.logging.log4j.message.EntryMessage
> org.apache.logging.log4j.message.ExitMessage
> org.apache.logging.log4j.message.FlowMessage
> org.apache.logging.log4j.message.FlowMessageFactory
> org.apache.logging.log4j.message.Message
> org.apache.logging.log4j.message.MessageFactory
> org.apache.logging.log4j.spi.LoggerContext
> org.apache.logging.log4j.spi.ExtendedLogger
> org.apache.logging.log4j.spi.LoggerContextFactory
> org.apache.logging.log4j.spi.LoggerRegistry
> org.apache.logging.log4j.spi.StandardLevel
> org.apache.logging.log4j.spi.ReadOnlyThreadContextMap
> org.apache.logging.log4j.util.BiConsumer
> org.apache.logging.log4j.util.ReadOnlyStringMap
> org.apache.logging.log4j.util.StringMap
> org.apache.logging.log4j.util.StringBuilderFormattable
> org.apache.logging.log4j.util.Supplier
> org.apache.logging.log4j.util.TriConsumer
> 
> Removing a method from any one of these can break user's code. Some of
> these (certainly `Supplier`, but to a smaller extent `Message`,
> `BiConsumer` and `TriConsumer`) are implemented by users, so even
> adding an abstract method to those, will break user code.
> 
> Piotr

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Piotr P. Karwasz]

Hi Ralph,

On Thu, 18 Jan 2024 at 18:18, Ralph Goers  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

Re: [log4j] Making Log4j 2 API "the Log4j API"

[Ralph Goers]

> On Jan 18, 2024, at 12:59 PM, Piotr P. Karwasz  
> wrote:
> 
> Hi Ralph,
> 
> On Thu, 18 Jan 2024 at 18:18, Ralph Goers  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

interesting writeup of some nice engineering

[Remko Popma]

https://www.uber.com/en-JP/blog/reducing-logging-cost-by-two-orders-of-magnitude-using-clp/

tldr:
Uber created a CLP

appender for log4j that compresses on the fly.
Impressive 169x compression rate.
Resulting compressed files are searchable because of embedded dictionaries.

Re: interesting writeup of some nice engineering

[Piotr P. Karwasz]

Hi Remko,

On Thu, 18 Jan 2024 at 23:16, Remko Popma  wrote:
>
> https://www.uber.com/en-JP/blog/reducing-logging-cost-by-two-orders-of-magnitude-using-clp/
>
> tldr:
> Uber created a CLP
> 
> appender for log4j that compresses on the fly.

Nice project! Unfortunately the Log4j appender is a Log4j 1.x
appender. There is also a Logback appender.

Piotr