On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote: > One of the difficulties was likely related to building the Windows DLLs > for > using the Windows Event Log Appender ( > https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html). > I remember that being challenging. I can't recall if we signed the DLLs > like we might do for Apache Commons Daemons Windows binaries. Another > hurdle.
Correct, the DLL is even in the codebase. https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll If we would remove that Appender, it would be much easier to build, when I remember correctly. Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK? > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies into > improving the 1.2 bridge and configuration file support we already have in > 2.x. That said, if we decides to move forward with 1.2.18, I'll help. > > No matter what, it needs to be a decision made carefully and not in haste. > +1 > Gary > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <grobme...@apache.org> > wrote: > >> Hello >> >> I have been the person cutting the 1.2.17 release and what I remember was >> it was a super hard build. I had to install some VMs because there were >> weird dependencies to this build. Building it fully will not be easy, but I >> can also look into some mails whatever I found from that time. >> Here is some build info.: >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL >> Some unit tests only run with a Windows VM >> >> It would be easier to remove some components, but BC is broken then. >> >> We told people in August 2015 this is EOL. I am honestly surprised that we >> discuss a new release after 7 years. To my understanding the JMSAppender >> issue is not as critical (just don't configure it). If a reconfiguration of >> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is. >> >> That said i don't think we should resurrect it. >> >> If somebody really wants to work on, I also don't think we should go >> through the incubator. We can do this using the normal processes and apply >> patches, vote on new committers etc. >> >> My 2 cents. >> >> Christian >> >> >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote: >> > Improving legacy compatibility is what I've been pushing. I agree with >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can >> of >> > worms. >> > >> > Gary >> > >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <boa...@gmail.com> wrote: >> > >> >> The alternative is to polish the 1.x compatibility in 2.x which is both >> >> actively maintained and much easier to get releases published. Then >> users >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that >> >> regardless of how many warnings we add to a potential 1.x release, we’ll >> >> get inundated with CVE reports, bug reports, and email, all related >> solely >> >> to 1.x which none of us wish to maintain (especially given most of us >> >> weren’t even involved in 1.x back when it was in development). >> >> -- >> >> Matt Sicker >> >> >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov < >> >> sitnikov.vladi...@gmail.com> wrote: >> >> > >> >> > Matt>but at least one release using the normal ASF release >> requirements >> >> is >> >> > required to graduate. >> >> > >> >> > Thanks for the reminder, and I am sure preparing the release won't be >> an >> >> > issue. I refactored release scripts for both Calcite and JMeter, and >> I am >> >> > sure log4j 1.x is doable. >> >> > >> >> >> compared to the alternatives discussed in this thread. >> >> > >> >> > I must be missing the alternarives. >> >> > Can you please highlight them? >> >> > >> >> > There were multiple suggestions and various PRs from external >> >> contributora, >> >> > yet the committers respond with vaugue messages. >> >> > >> >> > The code must be buildable, so moving to Git, and adding GitHub CI is >> the >> >> > mandatory step. >> >> > Of course, the existing PMC members and committers might have >> opinions on >> >> > the way to fix the issues, however I see no reasons for the team to >> deny >> >> > Git. >> >> > >> >> > The migration to Git consumes absolutely no resources from committers, >> >> > except a couple of +1 votes. >> >> > >> >> > Unfortunately, even a trivial improvement like Git is ignored by >> Logging >> >> > PMC. >> >> > >> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x >> >> > seriously. >> >> > >> >> > Vladimir >> >> >> >> >>
