It occurs to me that options 1 & 2 may not work well with OSGi and possibly JPMS. JPMS will require that the module have a unique name. It would need a module-info that specifies it requires org.apache.log4j. But users of this jar would be requesting org.apache.log4j and the jar would have to expose some other name. I have no idea how well that would work.
I think OSGi would have similar issues that might be even weirder to work around. Ralph > On Jan 27, 2022, at 12:30 PM, Matt Sicker <[email protected]> wrote: > > 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
