> On Dec 16, 2019, at 11:32 AM, Carter Kozak <[email protected]> wrote:
>
> Before we make large API changes for 3.x, I think it's worth considering the
> benefit compared to the churn (both for us, and log4j consumers) is worth it.
> Can we articulate the benefits of our API break, particularly the benefits
> that we cannot capture without breaking our API? Based on recent dev list
> traffic, we still have consumers on log4j 1.2, it would be great if we could
> avoid similar stratification as we move forward. The value proposition moving
> from log4j1.2 to log4j2 is substantial, we support orders of magnitude higher
> throughput and eliminated entire classes of bugs through the new
> architecture/threading model, and that hasn't been enough to push many
> consumers to upgrade from 1.2. I suppose my question is: If we break API and
> release a major revision, how do we make sure it's worth it?
>
I don’t believe you can. The stuff Gary is talking about is mostly cosmetic
stuff that users really don’t care about. They want a working API that is
flexible, easy to use, that they can count on. Sure adding stuff to it - like
the log builders we just added - are great but we shouldn’t take away stuff
that users already have in their application code.
In the latest update from Hadoop they said that they can’t upgrade from Log4j
1.x to Log4j 2 because they have customers who have hundreds of log4j1
configuration files that is too much effort for them to change. I am sure there
are many users who have lots of code using the log4j 1 Logger. We made that as
easy to switch from as we could but it is still too much work for many people
to bother with, so they use the bridge instead. But everyone hates using the
logging bridges because of the complexity and overhead it adds.
So while we do want to make significant changes in 3.0 we should not consider
it to be an opportunity to make the stuff users do - such as use the API and
write custom Plugins - incompatible.
Ralph
