Hi, Have you discussed the approach you outlined with the logging PMC? It seems to me the idea of a drop in jar that allows log4j 1 over log4j 2 is an ideal product for that PMC to support.
All the best, Dave Sent from my iPhone > On Dec 21, 2021, at 8:22 PM, 张铎 <palomino...@gmail.com> wrote: > > 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
