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