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 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 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 > > 1.2 releases, so it might as well stay in master/main/trunk. > > > > Gary > > > > On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory > wrote: > > > >> 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. > >>> > >>> 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? > > Gary > > > On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers < > >>> ralph.go...@dslextreme.com> > > 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 fails in the site plugin. > > > > If someone else wants to take this on I would suggest the first PR > >>> should > > just to the pom.xml file to get the build working as is. > > > > Ralph > > > > > > > >>> > >>> > >>> > >
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 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 > 1.2 releases, so it might as well stay in master/main/trunk. > > Gary > > On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory wrote: > >> 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. >>> >>> 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? Gary > On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers < >>> ralph.go...@dslextreme.com> > 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 fails in the site plugin. > > If someone else wants to take this on I would suggest the first PR >>> should > just to the pom.xml file to get the build working as is. > > Ralph > > > >>> >>> >>>
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 1.2 releases, so it might as well stay in master/main/trunk. Gary On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory wrote: > 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. >> >> 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? >> > >> > Gary >> > >> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers < >> ralph.go...@dslextreme.com> >> >> 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 fails in the site plugin. >> >> >> >> If someone else wants to take this on I would suggest the first PR >> should >> >> just to the pom.xml file to get the build working as is. >> >> >> >> Ralph >> >> >> >> >> >> >> >> >>
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. > > 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? > > > > 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 instructions and had to modify the javadoc > >> plugin to not fail on errors. Now it fails in the site plugin. > >> > >> If someone else wants to take this on I would suggest the first PR > should > >> just to the pom.xml file to get the build working as is. > >> > >> Ralph > >> > >> > >> > > >
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 'trunk' as long as we do it consistently across all Log4j repos; it would be best to be consistent across Logging Services project repos. Otherwise, I know I'll fat finger something ;-) Gary > -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, 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 instructions and had to modify the javadoc > >> plugin to not fail on errors. Now it fails in the site plugin. > >> > >> If someone else wants to take this on I would suggest the first PR > should > >> just to the pom.xml file to get the build working as is. > >> > >> Ralph > >> > >> > >> > >
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 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 >> looks like an overkill. >> >> I think there's no way to install Java 1.6 on modern macOS. > > Correct. I would suggest Docker, if there is a way to install it there. > > Here is some more installation instructions: > https://github.com/apache/logging-log4j1/blob/trunk/INSTALL > > For a complete build for a release, one needs to run tests using some DLLs > which made it very hard back then. > > Christian > > >> >> Vladimir >
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? > > 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 instructions and had to modify the javadoc >> plugin to not fail on errors. Now it fails in the site plugin. >> >> If someone else wants to take this on I would suggest the first PR should >> just to the pom.xml file to get the build working as is. >> >> Ralph >> >> >>
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, 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 instructions and had to modify the javadoc >> plugin to not fail on errors. Now it fails in the site plugin. >> >> If someone else wants to take this on I would suggest the first PR should >> just to the pom.xml file to get the build working as is. >> >> Ralph >> >> >>
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 instructions and had to modify the javadoc > plugin to not fail on errors. Now it fails in the site plugin. > > If someone else wants to take this on I would suggest the first PR should > just to the pom.xml file to get the build working as is. > > Ralph > > >
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 to all the increased attention to log4j. There’s some Java 6 installs. Rule of thumb: when I know of java 6 installs then a poor guy somewhere is maintaining a system like that on JDK 1.4. Practically, securing these systems is not hard. But, having dashboards go green “the easy way” needs an official upstream (or accepted redistributor) mitigation that is then runbooked and ideally automated. On the PRs I made you can use -P no-toolchain to build with any modern JDK that maven+plugins are happy with. Already proven with a working GitHub actions maven build. What’s so hard? Could you check if the -P no-toolchain setup works for you on Mac out of the box? It might also be good to add a patch to switch which build is default for convenience of the average Mac user. Cheers, Leo On Thu, 23 Dec 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 end of the day, making the build 100 times harder by requesting Java > 1.6 > looks like an overkill. > > I think there's no way to install Java 1.6 on modern macOS. > > Vladimir >
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 end of the day, making the build 100 times harder by requesting Java > 1.6 > looks like an overkill. > > I think there's no way to install Java 1.6 on modern macOS. Correct. I would suggest Docker, if there is a way to install it there. Here is some more installation instructions: https://github.com/apache/logging-log4j1/blob/trunk/INSTALL For a complete build for a release, one needs to run tests using some DLLs which made it very hard back then. Christian > > Vladimir
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 while we are still navigating this storm, means that we all have to make compromises and make a smooth path for the team, infra, users. This new repo is part of this smoother path. So, please don't get caught up in the mechanics, I encourage you to look toward the finish line. Allow me to relate what I am seeing in the enterprise and with organizations that provide professional services that might make this whole thing moot. As much as I explain the differences between Log4j 1 and 2 and the different issues that have occurred in both, the path is clear: People finally understand what end-of-life is and are moving toward Log4j 2. Let's skip the discussion of the Yossarian-like pickle for people who had already migrated and stepped into the RCE CVE. As I am advising these various people, some realize the 1.2 bridge will work fine, others have started rewriting their configuration in Log4j 2 XML on their own. All of this to say that, even though 1.2 might be safer within certain bounds, and made safer in the future, stacks are just moving to 2.x. HTH, Gary On Thu, Dec 23, 2021 at 7:25 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >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 > > Just in case you miss: > * What I really want to do here is to heal log4j 1.x for **everybody**. > That is why I want to get the canonical repository and the canonical Maven > coordinates. > * Of course, for my private applications, I have created and fixed log4j > 1.x **long ago**. > I just realized, this "private forks" effort is duplicated all over the > world, > and I realized the right thing to do is to fix the official log4j 1.x no > matter what "Logging PMC thinks of 1.x being EOL" > > Vladimir >
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 looks like an overkill. I think there's no way to install Java 1.6 on modern macOS. Vladimir
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 javadoc came onto trunk after 1.2.17. True that modern maven needs modern JDK, so setting up a compat build for 1.2.18 involved using maven toolchain feature. Cheers, Leo On Thu, 23 Dec 2021 at 13:18, Apache wrote: > 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 > >> 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 tests without any > problems. > > > > > > The 1.2.17 build as-is has only a short whitelist of tests being run from > > maven. There are many more tests only set up to run with ant, without > maven > > invoking ant. > > > > I changed the maven build to run all tests. Then set up a matrix build. > > Some of the other tests worked out of the box, not all. So then fixed the > > tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). > Disabled > > a couple really flaky ones. > > > > It then failed due to javadoc errors. > > > > > > Probably you used JDK9+ where some warnings become errors. I fixed that > too > > in a later commit by fixing the javadoc. You can also use older JDK > (IIRC 6 > > or 7). > > > > I just told the plugin not to fail and then it started executing the site > >> plugin. I tried updating the version but that just caused it to have an > >> error in the site.xml. > > > > > > Yup, fixing the site was a lot of work! > > > > My question is, you said that the build has test failures. Did I not see > >> them because of the changes after 1.2.17 or is something else going on? > > > > > > I think the summary answer here is “lots is going on”! > > 1.2.17 partially migrated the build from ant to maven 2, back in 2012. > > Frankly it wasn’t in so clean a state at time of release. > > That makes sense since all the plug-in stability in maven really only > came > > after maven 3. Back then it was pretty normal to work around plugin > > regressions every point release…you can see TODO comments in the 1.2.17 > pom > > about it… > > ….you may have forgotten the extent of such pain :-). Cleaning it all up > > was a bunch of explorative surgery! > > > > Cheers, > > > > Leo > > >
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 Just in case you miss: * What I really want to do here is to heal log4j 1.x for **everybody**. That is why I want to get the canonical repository and the canonical Maven coordinates. * Of course, for my private applications, I have created and fixed log4j 1.x **long ago**. I just realized, this "private forks" effort is duplicated all over the world, and I realized the right thing to do is to fix the official log4j 1.x no matter what "Logging PMC thinks of 1.x being EOL" Vladimir
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 >> 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 tests without any problems. > > > The 1.2.17 build as-is has only a short whitelist of tests being run from > maven. There are many more tests only set up to run with ant, without maven > invoking ant. > > I changed the maven build to run all tests. Then set up a matrix build. > Some of the other tests worked out of the box, not all. So then fixed the > tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled > a couple really flaky ones. > > It then failed due to javadoc errors. > > > Probably you used JDK9+ where some warnings become errors. I fixed that too > in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6 > or 7). > > I just told the plugin not to fail and then it started executing the site >> plugin. I tried updating the version but that just caused it to have an >> error in the site.xml. > > > Yup, fixing the site was a lot of work! > > My question is, you said that the build has test failures. Did I not see >> them because of the changes after 1.2.17 or is something else going on? > > > I think the summary answer here is “lots is going on”! > 1.2.17 partially migrated the build from ant to maven 2, back in 2012. > Frankly it wasn’t in so clean a state at time of release. > That makes sense since all the plug-in stability in maven really only came > after maven 3. Back then it was pretty normal to work around plugin > regressions every point release…you can see TODO comments in the 1.2.17 pom > about it… > ….you may have forgotten the extent of such pain :-). Cleaning it all up > was a bunch of explorative surgery! > > Cheers, > > Leo
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 rather than hunt that down and make everyone wait I created the new repo. All logging services Git repos start with logging-. Of course you are free to screw around and try to make something happen with the old repo rather than just getting started. Ralph > On Dec 23, 2021, at 4:56 AM, Vladimir Sitnikov > wrote: > > 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 one. > The existing repo is well-known in the community (108 watch, 537 forks, 849 > stars), and it is very strange to drop all that. > 2. Add GitHub CI so the code at least compiles. I think we should not fix > everything like javadoc/site/whatever if it takes too much time. > Having any CI would be way better than nothing. > 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of > RedHat fixes for log4j 1.x CVEs). > It might be easier to apply the fixes before the code is split. > 4. Consider splitting the code into modules. In practice, there's already a > branch that does exactly that: > https://github.com/apache/log4j/tree/log4j12modules/modules > 5. Release 1.2.18. > 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever. > 7. Release 1.2.19 > 8 see what happens, maybe new PR would appear. > > Vladimir
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 tests without any problems. The 1.2.17 build as-is has only a short whitelist of tests being run from maven. There are many more tests only set up to run with ant, without maven invoking ant. I changed the maven build to run all tests. Then set up a matrix build. Some of the other tests worked out of the box, not all. So then fixed the tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled a couple really flaky ones. It then failed due to javadoc errors. Probably you used JDK9+ where some warnings become errors. I fixed that too in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6 or 7). I just told the plugin not to fail and then it started executing the site > plugin. I tried updating the version but that just caused it to have an > error in the site.xml. Yup, fixing the site was a lot of work! My question is, you said that the build has test failures. Did I not see > them because of the changes after 1.2.17 or is something else going on? I think the summary answer here is “lots is going on”! 1.2.17 partially migrated the build from ant to maven 2, back in 2012. Frankly it wasn’t in so clean a state at time of release. That makes sense since all the plug-in stability in maven really only came after maven 3. Back then it was pretty normal to work around plugin regressions every point release…you can see TODO comments in the 1.2.17 pom about it… ….you may have forgotten the extent of such pain :-). Cleaning it all up was a bunch of explorative surgery! Cheers, Leo
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 fails in the site plugin. > > If someone else wants to take this on I would suggest the first PR should > just to the pom.xml file to get the build working as is. > > Ralph > > >
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 one. The existing repo is well-known in the community (108 watch, 537 forks, 849 stars), and it is very strange to drop all that. 2. Add GitHub CI so the code at least compiles. I think we should not fix everything like javadoc/site/whatever if it takes too much time. Having any CI would be way better than nothing. 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of RedHat fixes for log4j 1.x CVEs). It might be easier to apply the fixes before the code is split. 4. Consider splitting the code into modules. In practice, there's already a branch that does exactly that: https://github.com/apache/log4j/tree/log4j12modules/modules 5. Release 1.2.18. 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever. 7. Release 1.2.19 8 see what happens, maybe new PR would appear. Vladimir
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 plugin not to fail and then it started executing the site plugin. I tried updating the version but that just caused it to have an error in the site.xml. My question is, you said that the build has test failures. Did I not see them because of the changes after 1.2.17 or is something else going on? Ralph > On Dec 23, 2021, at 2:22 AM, Leo Simons wrote: > > (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 someone can take up to a5405370d844fca078c25f66654f929d07b1a922 from > > https://github.com/apache/log4j/pull/17 to make a PR to get to a modern > build. > > With some test failures because I got rid of the limited whitelist of unit > tests. Most of the commits after that set up GitHub actions and fix the > test suite. > > I expect you can safely take everything on that PR17 that is a commit that > does not start with “fix:” without much discussion. > > Each of those “fix:” commits from PR17 should then be a distinct PR and a > discussion, where based on Gary’s feedback most of them have a -1 against > them due to dropping functionality. > > Instead of or in addition to some of those fixes, a nice alternative > approach that Vladimir suggested before is to split off the more > problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their > own mini library jars. Then you can replace log4j-1.2.17.jar with > log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you > add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort. > > The third approach, the one Gary suggested, is to backport (the idea of) > more secure code from 2.x. > > Cheers, > > Leo > >> On Thu, 23 Dec 2021 at 07: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 fails in the site plugin. >> >> If someone else wants to take this on I would suggest the first PR should >> just to the pom.xml file to get the build working as is. >> >> Ralph >> >> >>
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 someone can take up to a5405370d844fca078c25f66654f929d07b1a922 from https://github.com/apache/log4j/pull/17 to make a PR to get to a modern build. With some test failures because I got rid of the limited whitelist of unit tests. Most of the commits after that set up GitHub actions and fix the test suite. I expect you can safely take everything on that PR17 that is a commit that does not start with “fix:” without much discussion. Each of those “fix:” commits from PR17 should then be a distinct PR and a discussion, where based on Gary’s feedback most of them have a -1 against them due to dropping functionality. Instead of or in addition to some of those fixes, a nice alternative approach that Vladimir suggested before is to split off the more problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their own mini library jars. Then you can replace log4j-1.2.17.jar with log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort. The third approach, the one Gary suggested, is to backport (the idea of) more secure code from 2.x. Cheers, Leo On Thu, 23 Dec 2021 at 07: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 fails in the site plugin. > > If someone else wants to take this on I would suggest the first PR should > just to the pom.xml file to get the build working as is. > > Ralph > > >
Re: New Log4j 1 repo
Ralph, thank you. Why did you create a new repository? AFAIK, infra could reopen the old one on request. Vladimir
Re: New Log4j 1 repo
https://github.com/apache/log4j was read-only. The new repo is not. Ralph > On Dec 22, 2021, at 11:34 PM, 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 fails in the site plugin. > > If someone else wants to take this on I would suggest the first PR should > just to the pom.xml file to get the build working as is. > > Ralph > >
Re: New Log4j 1 repo
Do read only mean we cannot give pull request？ Then how can I help you clean the pom correct... XenoAmess From: Ralph Goers Sent: Thursday, December 23, 2021 2:34:02 PM To: dev@logging.apache.org Subject: New Log4j 1 repo 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 fails in the site plugin. If someone else wants to take this on I would suggest the first PR should just to the pom.xml file to get the build working as is. Ralph
New Log4j 1 repo
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 fails in the site plugin. If someone else wants to take this on I would suggest the first PR should just to the pom.xml file to get the build working as is. Ralph
