OSGi seems to use re-packaged versions of Log4j2 most of the time anyways for some reason. See for example https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499613746/Configuring+Log4J2
On Fri, Feb 18, 2022 at 9:24 AM Ralph Goers <[email protected]> wrote: > > 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 >
