I'm the one who migrated HBase from log4j to log4j2, and still tries to migrate hadoop but still can not find a suitable upgrading path...
For me, I do not prefer we release a new log4j 1.x, it has been EOL for many years, we should encourage people to upgrade to a newer logging framework. FWIW, even if we make a new release for log4j, the projects which rely on log4j still need to upgrade and make a new release right? So then, I stand with Andrew's point, why people post an email here to get a new release for log4j 1.x, is mainly because they can not easily migrate to log4j2. If the log4j to log4j2 bridge can work perfectly, then for most old projects, they can just add a log4j12 bridge in the dependencies to solve most problems. And then they could start to migrate to pure log4j2 incrementally and finally remove the log4j12 bridge. But in my experience, first, the log4j12 bridge is not perfect. For example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge dependency if I want to run UTs based on hadoop mini cluster, and then I need to manually copy some code from log4j1 in order to make it work, this is an example https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java I know in the bridge you will create log4j2 appender instead when reading the configuration file of log4j1, but since the appenders in log4j1 lack of some abilities, it is common that lots of projects will implement their own appender, I think we should take care of these usages and make them migrate smoothly. And then, while fully migrating to log4j2, there is another annoying problem, the log4j.rootLogger=INFO,console grammar is gone! It is used among almost all the projects I've seen, and we just drop the support for it! In HBase, I have to do some magics in the start scripts to avoid breaking our users too much https://github.com/apache/hbase/blob/314e924e960d0d5c0c5e8ec436c75aaa6190b4c1/bin/hbase#L829 I really hope we could do better on backward compatibility, so when people ask for something about log4j1, we could just tell them to add the bridge to log4j2. And then easily fully migrate to log4j2 without too much effort if they want to use more features of log4j2, instead of finally making people ask here on whether they could revive log4j1... That's my real feeling while working on migrating from log4j1 to log4j2. Please correct me if I'm wrong. I'm also willing to help here on making the bridge works better and also making the migration easier. Thanks. Andrew Purtell <apurt...@apache.org> 于2021年12月22日周三 05:55写道： > > as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, > users who haven’t bothered to upgrade in 10 years will have to end up > paying astronomical costs for consultants who can still work on ancient > software effectively to help modify their systems. > > I have to take some exception to this. If the log4j 2.x configuration files > were compatible _enough_ with 1.x then taking this position would be > understandable. However, because they are not compatible in the way that > users require -- and the backwards compatibility is still marked as > 'experimental', even -- it is not great to blame users "who haven't > bothered to upgrade in 10 years". Turning this around, why is backwards > compatibility still experimental after 10 years? I am involved with several > Apache projects where we would love to upgrade from log4j 1 to log4j 2, and > have been talking about it for _years_. However, we have not been able to > easily do so because we actually care about operational cross-version > compatibility for our users. On some of these projects we are still stuck > on log4j 1. > > I also support continuing releasing for log4j 1.x, and would volunteer some > of my time to assist in the effort. > > > On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker <boa...@gmail.com> wrote: > > > Nobody in the Logging PMC is blocking a release here. What we don’t want > > is to falsely advertise that v1 is still under development. We already > have > > a huge increase in mailing list, PR, and other traffic ever since > > Log4Shell, and if we resurrect v1, then it’ll quickly become impossible > to > > keep up with all the activity given the size of the PMC. If any > non-trivial > > work is to be done in v1, we’d prefer to see more than one person working > > on that, especially if we want to add more PMC members to oversee v1 in > the > > first place. > > > > And as for the v1 :: COBOL analogy, that’s not a bad comparison. > > Basically, users who haven’t bothered to upgrade in 10 years will have to > > end up paying astronomical costs for consultants who can still work on > > ancient software effectively to help modify their systems. Was Maven even > > widely used back when v1 was popular? Or were people still using a mix of > > make or Ant? > > -- > > Matt Sicker > > > > > On Dec 21, 2021, at 07:13, Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > > > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli <eolive...@gmail.com> a > > > écrit : > > > > > >> Vladimir, > > >> I totally support this proposal. > > >> > > >> Which are actually the steps we need to cut a release of log4j 1.x ? > > >> - establish an Apache project ? > > >> > > > > > > 1. Send a patch to apply on > > > http://svn.apache.org/repos/asf/logging/log4j/trunk > > > > > > > > >> - do the fix > > >> > > > > > > 2. Get it applied > > > > > > > > >> - cut a release > > >> > > >> Can this be done inside another Apache Project who "adopts" the log4j > > >> sources if the Logging Project doesn't want to do it ? > > >> > > > > > > The PMC of log4j2 is logging project so it should be done there, if not > > the > > > project can be forked inside Apache but should change of package until > we > > > get the perms to reuse the same one which means likely as much work as > > just > > > getting it done at logging project so hope it is not needed ;). > > > > > > > > >> > > >> Enrico > > >> > > >> > > >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov < > > >> sitnikov.vladi...@gmail.com> ha scritto: > > >> > > >>>> Just wondering, is it even fulfilling the criteria of incubation? > > >>> > > >>> I believe, the world does not need "active development in log4j 1.x" > > >>> nowadays. > > >>> What everybody needs from log4j 1.x is to fix security issues, fix > > >>> outstanding issues (if any), > > >>> keep the project buildable (e.g. avoid using outdated build systems), > > >> etc. > > >>> > > >>>> it doesn't seem that sustainability is proven. > > >>> > > >>> The problem is log4j 1.x is like COBOL of logging. There are apps > that > > >> are > > >>> just stuck with log4j 1.x. > > >>> The proof of sustainability is that lots of existing apps will never > > >>> upgrade to 2.x because 2.x is incompatible. > > >>> If the compatibility layer of 2.x would be improved to handle 99.999% > > of > > >>> apps, > > >>> then we could indeed move 1.x to the attic. > > >>> > > >>> The Incubator Cookbook says: > > >>>> The ASF provides software for the public good, > > >>> > > >>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, > > and > > >>> there are **lots** of applications > > >>> that can't easily be upgraded to 2.x due to testing, configuration, > and > > >>> implementation issues. > > >>> > > >>> The current Logging PMC is focused on log4j 2.x only, and they have > no > > >>> desire to release 1.x > > >>> > > >>>> active development but focus only on CVE fixes > > >>> > > >>> I would say, the primary goal of resurrecting 1.x is to focus on > CVEs, > > >> and > > >>> keep the project buildable and testable. > > >>> However, it might be the case, that certain fixes or features would > > >> appear. > > >>> > > >>> The sad story is that the industry is using 1.x A LOT, and what > Logging > > >> PMC > > >>> did was > > >>> they ignored the community, and they just stopped maintaining 1.x and > > >>> focused on an incompatible 2.x > > >>> > > >>> Not only do they stop maintaining 1.x, but they also deny others to > > pick > > >> up > > >>> the maintenance task. > > >>> > > >>> What I am trying to do now is to pick up that maintenance activity. > > >>> > > >>> Vladimir > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
