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.
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. 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 > >> > >> >
