I'd be between options 1 and 2. I'm not a fan of duplicating the jar, though publishing an empty redirect jar isn't ideal either. Given that most of the intractable bugs in v1 were related to how log events are processed which now go through the v2 system, this seems like a good way to continue supporting users stuck on v1 for whatever reason. I assume that as a user, if I'm using 1.2.17, upgrading to 2.17.2 or whatever the next version ends up as, then simply bumping the version will be sufficient to pull in the rest of the Log4j2 dependencies needed here.
One potential alternative (though I'm not a fan of this one) would be to combine log4j-api, log4j-core, and log4j-1.2-api into log4j:log4j so it's still a single drop-in jar. That could cause further classpath issues, though, so I'd probably stick in favor of the first two options. On Thu, Jan 27, 2022 at 11:33 AM Ralph Goers <[email protected]> wrote: > > 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
