> On Jan 27, 2022, at 11:41 AM, Vladimir Sitnikov <[email protected]>
> wrote:
>
>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and
> javadoc jars renamed to log4j:log4j.
>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
>
> The options are bad as log4j-1.2-api misses several classes that are used a
> lot in log4j 1.x deployments.
> For instance, org.apache.log4j.jdbc.JDBCAppender.
That would put it on par with reload4j 2.18.1. That said, if the JDBCAppender
was fixed in
reload4j we can either copy it into log4j-1.2-api as a log4j 1.x appender or
reimplement
it as a log4j 2 appender.
If there are other classes that are required you are invited to submit PRs to
address them.
>
> If you release that as log4j:log4j:2.x, then you trigger a lot of
> non-workable update suggestions.
>
> ----
>
> Then, if you think log4j-1.2-api:2.x is good enough to replace
> log4j:log4j:1.x, then you basically say
> "all the issues in 1.x can be solved without breaking backward
> compatibility".
> I am afraid that contradicts Ron's message:
> https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w
It absolutely does not. The issues in Log4j 1.x are in the core of how it
processes log
events. Log4j 2 doesn’t suffer from any of those issues.
Instead of continuing to be a gnat and arguing against Log4j2 you could start
being part
of the solution and work to improve the bridge.
This thread is not about discussing why reload4j is better than log4j-1.2-api.
That
discussion is over. If you continue on that path you will be put into
moderation.
However, if you can provide a better way to let users migrate to Log4j2 we will
be
happy to hear it.
Ralph
