Investigate forks

[vlsi]

There are forks that might be worth exploring and joining forces:

• https://github.com/Netflix/blitz4j
• TBD

[ceki]

blitz4j does not look like a fork of log4j but a very different project.

[grgrzybek]

https://github.com/ops4j/org.ops4j.pax.logging in branches before 1.11 are actual forks. See https://github.com/ops4j/org.ops4j.pax.logging/tree/pax-logging-1.10.x/pax-logging-service/src/main/java/org/apache/log4j
I'm preparing a review of the releases and I'll share it soon.

[hazendaz]

Not sure if any value from this fork https://github.com/albfernandez/log4j. This was used for richfaces 4.x continued support. The richfaces fork repo itself was just flipped to reload4j on this PR albfernandez/richfaces#69 but saw this ticket and tought I'd add it to the list.

[grgrzybek]

For Pax Logging, these are the _active_branches:

• main - current 2.1.x branch (OSGi CMPN R7) without log4j1 backend (in other areas, compatible with 2.0.x)
• 2.0.x - 2.0.x branch (OSGi CMPN R7) with log4j1 backend with several shaded log4j1 classes - only the classes that needed OSGi adjustments are stored in pax.logging repo - other ones are used with maven-dependency-plugin
• 1.12.x - 1.12.x branch (OSGi CMPN R6) without log4j1 backend is compatible with 1.11.x branch in all other aspects
• 1.11.x - 1.11.x branch (OSGi CMPN R6) with log4j1 backend - several shaded classes as in 2.0.x.
• 1.10.x - 1.10.x branch (compatible with 1.11.x, but before my refactoring and adding integration tests) - in reality, this is maintained only for special users only. Shades much more classes from log4j1 - even the ones that don't need OSGi adjustment. However JMSAppender is not shaded.

The plan is to switch 1.11.x and 2.0.x branches from log4j/log4j to ch.qos.reload4j/reload4j dependency and reapply the OSGi-related adjustments - after JDBC/JMS/SMTP/Socket related CVEs are done in reload4j (I see JDBCAppender and SMTPAppender are still being worked on).

Thank you very much @ceki for your great work on the fork.
From my perspective, maintaining the legacy and history of Java libraries is very important aspect of entire Java ecosystem that makes it the best choice for safe, long term IT investment.

I worked (and I'm still working) on many legacy, not-cool-lambda-µservice-hyper-mesh-cloud technologies (CORBA, OSGi) and getting positive feedback from people still using and relying on them is very motivating. Remember - not everyone runs their enterprise on one-line-lambda-no-code-functions-and-µservices...

[ceki]

By the way, version 1.7.34 of slf4j-log4j12 will automatically redirect to slf4j-reload4j by means of Maven relocation element. Initial tests show that relocation works quite well. (The relocation idea was suggested by @vlsi )

[aairey]

https://bitbucket.org/atlassian/log4j1/src/master/