Log4j 2.17.2 is going to contain at least 3 dozen fixes or improvements to the
log4j 1.2
support. One of our PMC members has been actively working on migrating his
employer’s
applications from Log4j 1.x to log4j-1.2-api and has had great success. We have
also
had users experience issues and try the 2.17.2-SNAPSHOT and verify it fixes
their problems.
We would love more feedback on the support.
That said, due to the positive experience we have discussed a way to make
migration from
log4j 1 to log4j 2 even easier. Our thought has been to publish an artifact as
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j2.version}</version>
This would be part of the log4j 2 release. Thus users could just change the
log4j 1 version
in the dependencyManagement section of their parent pom and automatically start
using the
bridge.
I’ve personally spoken to a few non-PMC members and gotten positive feedback on
the idea,
but I would like more input. One of the issues is what the artifact should
contain. Here are
a few options:
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.
3. Use the relocation trick that SLF4J used to obliterate its log4j-1.2
support. Thus the log4j 1.x
pom.xml would redirect users to the log4j-1.2-api dependency.
Each of these has pros and cons.
1. You have 2 jars with the same stuff. If somehow both are on the classpath
one will override
the other, which shouldn’t be a problem if both are the same version.
2. If the jar file is empty it can’t conflict with anything. But it could be
confusing to users who
are looking for log4j to find it as an empty jar.
3. It isn’t really clear how well the relocation trick works. SLF4J immediately
got 2 Jira issues
created from users who said they were having problems.
So before we implement a solution I would like feedback from the folks who
monitor this list.
Thanks,
Ralph
