On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <grobme...@apache.org> wrote:
> > 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? > Sadly, no. We cannot break binary compatibility, that would create a bigger mess: Jar hell. Some folks would argue for breaking BC but that's a no-go me. I feel like the projects I've worked on like Apache Commons and HttpComponents have benefitted *massively* from providing binary compatibility. Giving users drop-in replacements is a huge help. Recall that Apache officially *only releases source code*, and that source code must be buildable, no matter how complex the instructions. Any binaries are only provided as a convenience, that includes jar files and DLLs. Gary > > > > 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 > >> >> > >> >> > >> >
