Re: Resurrecting log4j 1.x

Vladimir, There is a vote thread in progress ( https://lists.apache.org/thread/0rk0nr0pv9p2945jsrs9pp2ys57wksn3). You and I both voted on that thread. Looking at the number of +1 votes on that voting thread, surely you can see that this repo will be created, and not only that, it will be created *

Re: Resurrecting log4j 1.x

Christian>Here is some more information on how we develop software: Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok? >as a community, need to find consensus first Could you please stop going in circles and just agree to open apache/log4j Git for writes? Are there another v

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

The Log4j1 project is EOL, and assuming that it remains EOL and we are only doing security patches, I vote in favor of this repo change, to facilitate making such security patches. +1 I agree we need to get consensus on the scope of any Log4j1 work. On Fri, Dec 24, 2021 at 8:53 AM Matt Sicker wr

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

The Log4j1 project is EOL, and assuming that it remains EOL and we are only doing security patches, I vote in favor of this repo change, to facilitate making such security patches. +1 I agree we need to get consensus on the scope of any Log4j1 work. On Fri, Dec 24, 2021 at 8:55 AM Ralph Goers w

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

That will be the next separate discussion and vote. Ralph > On Dec 23, 2021, at 4:53 PM, Matt Sicker wrote: > > I tend to agree here. Even if we go ahead with the repo rename, we’ll still > need some consensus on the scope of this work. > -- > Matt Sicker > >> On Dec 23, 2021, at 17:11, Chris

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

I tend to agree here. Even if we go ahead with the repo rename, we’ll still need some consensus on the scope of this work. -- Matt Sicker > On Dec 23, 2021, at 17:11, Christian Grobmeier wrote: > > hi > > at the moment I am -1 too, mostly for the reasons Gary mentioned. > Most important is tha

Re: Log4J 1.x progress, pull request(s), plans

On Thu, Dec 23, 2021, at 16:39, Leo Simons wrote: > On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier > wrote: > >> I didn't see the PRs though - are they still local on your box? > > > On the wrong repo and lacking a target branch: > > https://github.com/apache/log4j/pull/17 > https://github.co

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

hi at the moment I am -1 too, mostly for the reasons Gary mentioned. Most important is that we don't have a clear goal on what we are trying to achieve here. We should be very explicit of why we are doing what. Cheers, Christian On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote: > -1 > We jus

Re: Resurrecting log4j 1.x

Hello Vladimir, On Thu, Dec 23, 2021, at 20:58, Vladimir Sitnikov wrote: > Christian>if you send in patches there are people who would apply them > > Thank you. > Let us see what INFRA says regarding https://github.com/apache/log4j in > https://issues.apache.org/jira/browse/INFRA-22654 This is no

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 On Thu, Dec 23, 2021 at 4:55 PM Vladimir Sitnikov wrote: > > +1 > > Please use the existing apache/log4j repository, and rename it accordingly > > Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 Please use the existing apache/log4j repository, and rename it accordingly Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

These are some good points, Gary. -- Matt Sicker > On Dec 23, 2021, at 15:50, Gary Gregory wrote: > > -1 > We just created logging-log4j1 and converted the SVN repo into it, let's > stick to that. I even made a commit ;-) > I claim it is a good thing to start with a new repo because it creates a

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

-1 We just created logging-log4j1 and converted the SVN repo into it, let's stick to that. I even made a commit ;-) I claim it is a good thing to start with a new repo because it creates a tiny bit of friction, for a project that is still End-of-Life after all. Even if it is a bit of friction to br

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 On Thursday, December 23, 2021, 04:45:14 PM EST, Matt Sicker wrote: +1 -- Matt Sicker > On Dec 23, 2021, at 15:41, Dominik Psenner wrote: > > +1 > > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Thu, Dec 23, 2021, 22:38 Ralph Goers

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 -- Matt Sicker > On Dec 23, 2021, at 15:41, Dominik Psenner wrote: > > +1 > > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Thu, Dec 23, 2021, 22:38 Ralph Goers wrote: > >> +1 >> >> Ralph >> >>> On Dec 23, 2021, at 2:35 PM, Ralph Goers >> w

[VOTE] Release Apache Log4j Scala API version 13.0-rc1

This is a vote to release Log4j Scala API 13.0. This release primarily adds support for Scala 3. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for 72 hours (or more if required). All

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Thu, Dec 23, 2021, 22:38 Ralph Goers wrote: > +1 > > Ralph > > > On Dec 23, 2021, at 2:35 PM, Ralph Goers > wrote: > > > > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus > has recommend

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 Ralph > On Dec 23, 2021, at 2:35 PM, Ralph Goers wrote: > > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has > recommended that we can divorce > the read-only SVN repo from https://github.com/apache/log4j. However, it will > not be able to keep the same > name as a

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

+1 -ck > On Dec 23, 2021, at 16:35, Ralph Goers wrote: > > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has > recommended that we can divorce > the read-only SVN repo from https://github.com/apache/log4j. However, it will > not be able to keep the same > name as all

[VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has recommended that we can divorce the read-only SVN repo from https://github.com/apache/log4j. However, it will not be able to keep the same name as all Git repos owned by the logging project must start with “logging-“. So t

Re: Configuration element for system properties

Judging from the PropertiesUtil, it is indeed not a typo but an undocumented feature. I think we shouldn't have any undocumented features; created LOG4J2-3287 . A slightly related issue I have raised in 2019 was making constants a part of the conf

Re: [VOTE] Release log4net 2.0.14

Root keys are in https://downloads.apache.org/logging/KEYS which is in the dist repository where you commit releases. On Mon, Dec 20, 2021 at 2:03 AM Dominik Psenner wrote: > > * old-log4net.snk.gpg has been the old key to sign binaries. > * @Matt, where is the root logging KEYS file located? > >

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 4 rc1

I'll add a +1 here. This vote passes with 3 +1 votes. I'll release to Maven Central along with a rel/ tag. On Thu, Dec 23, 2021 at 1:54 PM Matt Sicker wrote: > > It should be a tag named logging-parent-4. > > On Thu, Dec 23, 2021 at 3:48 AM Volkan Yazıcı wrote: > > > > +1 > > > > I see that the

Re: Resurrecting log4j 1.x

Dominik, The branch named “main” has been created from the v1_2_17 tag. I have created a ticket to have that branch made the GitHub default branch. Once that is done we can rename trunk to something else or delete the branch entirely. Ralph > On Dec 23, 2021, at 1:21 PM, Dominik Psenner wrot

Re: Resurrecting log4j 1.x

So far it has been discussed to patch 1.2.17. I propose to fork logging-log4j1 [1] and base improvements on tag v1_2_17, de9f0ea. As far as I can tell, no additional work is required from Infra or Logging Services. [1] https://github.com/apache/logging-log4j1 -- Sent from my phone. Typos are a ki

Re: Resurrecting log4j 1.x

Christian>if you send in patches there are people who would apply them Thank you. Let us see what INFRA says regarding https://github.com/apache/log4j in https://issues.apache.org/jira/browse/INFRA-22654 Vladimir

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 4 rc1

It should be a tag named logging-parent-4. On Thu, Dec 23, 2021 at 3:48 AM Volkan Yazıcı wrote: > > +1 > > I see that the changes are committed and the `logging-parent-4` branch has > been deleted. > I also see the `logging-parent-4` line in `pom.xml`. Shouldn't > this be HEAD instead? > > On Sun

Re: Resurrecting log4j 1.x

Hello On Thu, Dec 23, 2021, at 18:07, Vladimir Sitnikov wrote: > Dominik> There are fixes for the flaws of log4j1 available: migrate to > log4j2 > > How does migration help me if I want to get 1.x fixed? > log4j2 is a different product, created by a different team. > Why should I migrate to log4j2

Re: Log4J 1.x progress, pull request(s), plans

Leo, I have created the main branch from the v1_2_17 tag. It looks like I will have to create a Jira for Infra to switch the default as it looks like we don’t have access to the GitHub tooling to do that. Ralph > On Dec 23, 2021, at 8:39 AM, Leo Simons wrote: > > On Thu, 23 Dec 2021 at 15:

Re: Resurrecting log4j 1.x

> On Dec 23, 2021, at 10:07 AM, Vladimir Sitnikov > wrote: > > > Do you know migration to 2.x is not a drop-in replacement? > It might require code or non-trivial configuration changes? > For instance, if the application extends 1.x appenders, implements > non-trivial re-configuration logic,

Re: Broken CI

I rarely have issues running tests from the mvn command line. Whatever we have set up in GitHub seems quite complicated compared to most projects I've seen. From Eclipse, sometimes tests fail, but I never researched it, the mvm cmd line is what matters most anyway. G Gary On Thu, Dec 23, 2021, 1

Re: Broken CI

My issues were all on master. I've always been able to work on release-2.x in IntelliJ or Eclipse without any issue. I'll have to check out master and see if it works now. I have it on the back burner to try to figure out an improved status logger life cycle. On Thu, Dec 23, 2021 at 9:34 AM Carte

Re: Broken CI

I haven't had a test flake locally in the last 6 months (at least), if we see flaky tests I'm in favor of fixing them rather than working around them. fwiw the non GitHub-actions tests work great on the release-2.x branch in my experience, when they aren't overwhelmed accessing build nodes anyho

Re: Broken CI

I'm not talking about failing tests but about some other build silliness that does not feel necessary, for example: https://github.com/apache/logging-log4j2/runs/4620228443?check_suite_focus=true Shows: Run scacap/action-surefire-report@v1 Going to parse results form **/*-reports/TEST-*.xml Resu

Re: Broken CI

Is it worth marching those tests with @Ignore and filing a Jira for each one? That does seem to set a bad precedent though. Last time I tried I couldn't get the mainline code to load in IntelliJ or Eclipse because of the packing changes that were in progress. Did that get fixed? If so, I might be

Re: Resurrecting log4j 1.x

Dominik> There are fixes for the flaws of log4j1 available: migrate to log4j2 How does migration help me if I want to get 1.x fixed? log4j2 is a different product, created by a different team. Why should I migrate to log4j2 at all? Dominik>Is there a concrete need for log4j1 to be patched 1. I r

Re: Resurrecting log4j 1.x

There are fixes for the flaws of log4j1 available: migrate to log4j2. Is there a concrete need for log4j1 to be patched and that need cannot be satisfied by migrating to log4j2? -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Thu, Dec 23, 2021, 16:39 Vladimir

Re: Resurrecting log4j 1.x

>Again: References, please, otherwise you're just making FUD. CVE-2019-17571 CVE-2021-4104 there might be others Once again: CVEs in 1.x are real (it exists now). "pull requests created for 1.x" is theoretical (it does not exist now, and it does not harm if that really happens). Vladimir

Re: Resurrecting log4j 1.x

On Thu, Dec 23, 2021 at 11:14 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >A, so in fact "1.x has LOTs of known CVEs." translate to one CVE. > > This is false. > There are multiple CVEs. > Again: References, please, otherwise you're just making FUD. > The vulnerabilities ha

Re: Resurrecting log4j 1.x

>A, so in fact "1.x has LOTs of known CVEs." translate to one CVE. This is false. There are multiple CVEs. The vulnerabilities have different attack vectors and different consequences. Vladimir

Re: Resurrecting log4j 1.x

On Thu, Dec 23, 2021 at 11:05 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > >Where is this CVE tonnage? > > JMSAppender > JMSSink > chainsaw > SocketServer > infinite recursion (1.x does have some recursive code trying to replace > variables) > > > I do not know CVE numbers, y

Re: Resurrecting log4j 1.x

>Where is this CVE tonnage? JMSAppender JMSSink chainsaw SocketServer infinite recursion (1.x does have some recursive code trying to replace variables) I do not know CVE numbers, yet I just see the bugs are there. Vladimir

Re: Resurrecting log4j 1.x

>Now we have a real issue: 1.x has LOTs of known CVEs. >Could we refrain from theoretical discussions? We document CVE-2019-17571/ Where is this CVE tonnage? Gary On Thu, Dec 23, 2021 at 10:39 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Volkan>To the best of > Volkan>my knowle

Re: Resurrecting log4j 1.x

> I think we will try to meet once or twice a month primarily to >reduce that backlog. If you ever figure out the solution, please tweet or blog on that (or at least mention me). I think ANY successful project ends up in 100500 open issues. For instance: https://cwiki.apache.org/confluence/displa

Re: Resurrecting log4j 1.x

> On Dec 23, 2021, at 8:38 AM, Vladimir Sitnikov > wrote: > > > For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever > fix all of them :) Actually, in the midst of working on the CVEs we discussed this. We have found that Slack calls work really well for us so I thi

Re: Log4J 1.x progress, pull request(s), plans

On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier wrote: > I didn't see the PRs though - are they still local on your box? On the wrong repo and lacking a target branch: https://github.com/apache/log4j/pull/17 https://github.com/apache/log4j/pull/16 From https://github.com/lsimons/log4j For

Re: Resurrecting log4j 1.x

Volkan>To the best of Volkan>my knowledge, nobody has reached out to us with such a request except you Volkan>and Leo I think they just swallowed the pill that "1.x is marked EOL", and they did workarounds. a) make security team understand "the CVEs of 1.x are not that impactful for them" b) make

Re: Broken CI

Since, there are some tests which occasionally constantly fail, we use `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a build with test failures to be marked green. The 3rd party component, `scacap/action-surefire-report@v1`, is used to feed these failures back into GitHub Actions

Re: Resurrecting log4j 1.x

Vladimir, mind helping us to quantify this "need", please? To the best of my knowledge, nobody has reached out to us with such a request except you and Leo. Is it a gut feeling that is the basis of your justification or is there an explicit demand from the community that I am missing? I also did no

Re: New Log4j 1 repo

Cute :-) But... Over at Apache Commons, we just dropped all trunk branches a long time ago. No renames, it's simpler IMO. Gary On Thu, Dec 23, 2021 at 9:57 AM Ralph Goers wrote: > I am planning on creating a branch off the 1.2.17 tag. That branch will be > named main. > I will make that the def

Re: New Log4j 1 repo

I am planning on creating a branch off the 1.2.17 tag. That branch will be named main. I will make that the default branch. Then I plan to rename trunk to a nice name like DEAD-HEAD (GRATEFUL) Ralph > On Dec 23, 2021, at 7:20 AM, Gary Gregory wrote: > > A name like "version" should only be f

Re: Log4J 1.x progress, pull request(s), plans

Hi On Thu, Dec 23, 2021, at 14:51, Leo Simons wrote: > Thanks for chipping in Christian! Your detailed notes from back then helped > a ton figure basic things out. > > What I did for the PRs I made is to > > * also check in the 32 bit 1.2.17 dll from the binary release, like was > already done for

Re: Log4J 1.x progress, pull request(s), plans

Gary>If you manage your Maven (for example) POM properly, Gary>and you assemble a distribution you'll only end up with the latest version. Then I don't truly understand what did you mean by mentioning "Jar hell". I claim that removal of NTEventLogAppender can't cause "jar hell" because people eit

Re: Log4J 1.x progress, pull request(s), plans

On Thu, Dec 23, 2021 at 8:48 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Gary, > > If someone manages to have **both** log4j-1.2.17.jar **and** > log4j-1.2.18.jar > on the same classpath, nothing can help them. Really. > Binary compatibility can't heal that. > You're confusing ma

Re: New Log4j 1 repo

A name like "version" should only be for tags. Once a version is released, it does not make sense to have a branch by that name, but it would be OK to have a name for a "maintenance line", as we did with "2.12.x", so here we would have "1.2.x" which is lame IMO because we're ONLY EVER going to have

Re: New Log4j 1 repo

WAIT, what? That does not make sense, it's the same bad name we ended up in with the "2.12" branch instead of "2.12.x". Gary On Thu, Dec 23, 2021 at 8:50 AM Apache wrote: > I was already asked to create a branch off of 1.2.17. It will become the > main branch so trunk can be left alone. > > Ral

Re: New Log4j 1 repo

On Thu, Dec 23, 2021 at 8:43 AM Carter Kozak wrote: > I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all > our projects). > We use 'develop' and 'master' w/i the same repos at work so that would not help my brain :-) but I am OK changing the name to something else than 't

Re: Log4J 1.x progress, pull request(s), plans

Fwiw, this sounds like a god plan to me. Ralph > On Dec 23, 2021, at 6:51 AM, Leo Simons wrote: > > Thanks for chipping in Christian! Your detailed notes from back then helped > a ton figure basic things out. > > What I did for the PRs I made is to > > * also check in the 32 bit 1.2.17 dll f

Re: New Log4j 1 repo

I have VMWare on my Mac with both Ubuntu and Windows 10. So I should be able to run a build. Ralph > On Dec 23, 2021, at 5:59 AM, Christian Grobmeier wrote: > > Hi, > > > On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote: >>> using maven toolchain feature >> >> Are toolchains really

Re: Log4J 1.x progress, pull request(s), plans

Thanks for chipping in Christian! Your detailed notes from back then helped a ton figure basic things out. What I did for the PRs I made is to * also check in the 32 bit 1.2.17 dll from the binary release, like was already done for 64 bit, * have the maven build not auto-attempt to build it, * ma

Re: New Log4j 1 repo

I was already asked to create a branch off of 1.2.17. It will become the main branch so trunk can be left alone. Ralph > On Dec 23, 2021, at 6:41 AM, Gary Gregory wrote: > > If we use this repo, is everyone OK renaming "trunk" to "master" in order > to match the branch name of our other repos

Re: Log4J 1.x progress, pull request(s), plans

Gary, If someone manages to have **both** log4j-1.2.17.jar **and** log4j-1.2.18.jar on the same classpath, nothing can help them. Really. Binary compatibility can't heal that. Even if 1.2.18 was fully binary compatible, adding both jars to the classpath would blow the system anyway. In other wor

Re: New Log4j 1 repo

I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all our projects). -ck > On Dec 23, 2021, at 08:41, Gary Gregory wrote: > > If we use this repo, is everyone OK renaming "trunk" to "master" in order > to match the branch name of our other repos? > > Gary > >> On Thu, D

Re: New Log4j 1 repo

If we use this repo, is everyone OK renaming "trunk" to "master" in order to match the branch name of our other repos? Gary On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers wrote: > I have cloned the read-only log4j repo to > https://github.com/apache/logging-log4j1. > > I have followed the build in

Re: Log4J 1.x progress, pull request(s), plans

On Thu, Dec 23, 2021 at 8:31 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK? > > I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a > silence system property is set) > appender would be more

Re: Log4J 1.x progress, pull request(s), plans

On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 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/

Re: Log4J 1.x progress, pull request(s), plans

>Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK? I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a silence system property is set) appender would be more than enough for 1.2.18 If the appender is not used in the wild, we are ok. If somebody still uses

Re: Log4J 1.x progress, pull request(s), plans

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 challe

Re: New Log4j 1 repo

Hey, I am interested in legacy/vintage core enterprise systems deep inside large enterprises and governments, where source code changes are out of the question, that have lit up yellow in security/compliance dashboards due to the old CVE against log4j 1.2 for years, that now light up as orange due

Re: Log4J 1.x progress, pull request(s), plans

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

Re: New Log4j 1 repo

Hi, On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote: >>using maven toolchain feature > > Are toolchains really needed, especially, 1.6 and 1.7? > I believe Java "target=1.4" + Java 1.8 would be good enough. > If there are javadoc "warnings or errors", we could just suppress it. > At the e

Re: New Log4j 1 repo

Vladimir, I appreciate your energy and your enthusiasm, I do, but you're going to have to pick your battles IMO. I would say we (not but really wearing my PMC hat) have passively agreed that we can move toward fixing CVEs and potential CVEs in what would be a 1.2.18. For us to get there and whil

Re: Log4J 1.x progress, pull request(s), plans

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

Re: New Log4j 1 repo

>using maven toolchain feature Are toolchains really needed, especially, 1.6 and 1.7? I believe Java "target=1.4" + Java 1.8 would be good enough. If there are javadoc "warnings or errors", we could just suppress it. At the end of the day, making the build 100 times harder by requesting Java 1.6 l

Re: New Log4j 1 repo

Hmm my best guess still is the javadoc warning>error. I didn’t think that started with JDK 8… The PR I had made for trunk has this fix for it https://github.com/apache/log4j/pull/16/commits/490255fbe6a3bc729c09be8ff36b6c965029d67c For the 1.2.17 PR that commit is not there, probably the broken j

Re: New Log4j 1 repo

>All logging services Git repos start with logging-. I'm 100% sure INFRA can rename `apache/log4j` into `apache/logging-log4j1`, and it would be transparent for GitHub users. GitHub would automatically redirect from apache/log4j to apache/logging-log4j1 >Of course you are free to screw around Ju

Re: New Log4j 1 repo

Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think maven 3 runs on Java 6. Ralph > On Dec 23, 2021, at 5:11 AM, Leo Simons wrote: > > On Thu, 23 Dec 2021 at 12:39, Ralph Goers > wrote: > >> It is still the middle of the night for me so I won’t do anything for >> severa

Re: New Log4j 1 repo

From what I can tell that repo could only be “owned” by a TLP named log4j.apache.org. It doesn’t show up on the list of gitbox repos owned by any ASF projects. I believe it is a read-only mirror tied to the sun repo. I asked infra about it in slack and they weren’t quite sure what it is. So rath

Re: New Log4j 1 repo

On Thu, 23 Dec 2021 at 12:39, Ralph Goers wrote: > It is still the middle of the night for me so I won’t do anything for > several hours. Whoa, best get some rest! :) I will create the branch but I am curious about the rest. When I ran the > build last night it ran through a bunch of unit test

Re: New Log4j 1 repo

Well done Ralph, I'll take a look today. Gary On Thu, Dec 23, 2021, 01:34 Ralph Goers wrote: > I have cloned the read-only log4j repo to > https://github.com/apache/logging-log4j1. > > I have followed the build instructions and had to modify the javadoc > plugin to not fail on errors. Now it fa

Re: New Log4j 1 repo

Leo>Instead of or in addition to some of those fixes I would suggest the following (in case you wonder, I might volunteer to do ALL of that, so don't assume I just sit and tell others how things should be done): 1. Use the existing repo https://github.com/apache/log4j instead of a newly created on

Re: New Log4j 1 repo

Leo, It is still the middle of the night for me so I won’t do anything for several hours. I will create the branch but I am curious about the rest. When I ran the build last night it ran through a bunch of unit tests without any problems. It then failed due to javadoc errors. I just told the pl

Re: SocketAppenderReconnectTest still flaky on mac 11.8.1; raising timeout to 15 sec helps

Thanks for the feedback. Incorporated some changes to both `master` and `release-2.x`. On Mon, Dec 20, 2021 at 7:49 PM Dan Kegel wrote: > My build procedure for the release-2.x branch succeeded on mac > 10.16.7, but is failing one lousy test on mac 11.8.1: > > > SocketAppenderReconnectTest.recon

Re: Zero-copy rolling files

*[I am Log4j rollover illiterate, hence apologies in advance if I am saying something stupid.]* Why don't we simply rename files and create new ones? That is, `mv applog.txt applog-2021.txt` and `touch applog.txt`? I use this in my RotatingFileOutputStream and

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 4 rc1

+1 I see that the changes are committed and the `logging-parent-4` branch has been deleted. I also see the `logging-parent-4` line in `pom.xml`. Shouldn't this be HEAD instead? On Sun, Dec 19, 2021 at 11:40 PM Matt Sicker wrote: > Hi all, this is a lazy vote to release the latest changes to our

Re: LOG4J2-3243

Thanks for the clarification. I will try to enumerate all the cases below: *[Below, 1, 2, and B denote Log4j 1, Log4j 2, and log4j-1.2-api, respectively.]* *1/2/B:* failure, both 1 and B cannot be present (equivalent to #1 in your enumeration) *1/2/-:* 2 should detect `log4j.configuration`, yet d

Re: New Log4j 1 repo

(On mobile) Cool. First I suggest to make a new branch from 1.2.17. Trunk has various stuff that’s backwards incompatible. Something like git checkout -b main v1_0_2_17 git push -u main Then go into GitHub settings and make main the default branch. So then people make PRs against that. Think