Dear Log4j community, While working on the December 2021 Apache Log4j 2 releases the Apache Logging Services PMC received requests to reevaluate the 2015 End-of-Life (EOL) decision for Apache Log4j 1, which has seen its latest release in 2012.
We have considered these requests and discussed various options. Ultimately we came to the unanimous decision that the only sustainable approach is to continue to focus on Log4j 2. The PMC hereby reconfirms the 2015 EOL announcement of Log4j 1, meaning no resources will be invested into the Log4j 1 codebase. We encourage users to update to recent versions of Log4j 2. We welcome every effort to contribute to the Log4j community. Please use the developer mailing lists to get in touch: https://logging.apache.org/log4j/2.x/mail-lists.html The Log4j 1 source code will continue to be publicly available but Pull Requests will be closed as "Won't Fix". The Apache License allows for code forks that respect Apache Software Foundation Trademarks. Here are some of the reasons we believe this is the right choice for the Log4j project: * Log4j 2 supports migration from Log4j 1 We've made improvements to https://logging.apache.org/log4j/2.x/manual/migration.html to better explain the process. Many users are not aware that Log4j 2 now supports Log4j 1 configuration files, since this feature is relatively new. We believe most applications using Log4j 1 can now simply replace the Log4j 1.x jar with Log4j 2 jars and be able to run. Users are encouraged to contact us through the project mailing lists (https://logging.apache.org/log4j/2.x/mail-lists.html) if there are additional areas for improvement. * Log4j 1 deadlock and multithreading design limitations The decision to relaunch the Log4j project as Log4j 2 meant we had an opportunity to correct long standing design deficiencies. One of these fundamental design deficiencies has to do with how to handle multithreading within the library. The following mailing list question is but one example of known multithreading issues with Log4j 1: https://lists.apache.org/thread/7yqrmzqgzpxmbcc7skl0vr8z33fk4hd4 * High-complexity Log4j 1 bugs In addition to the items listed, many other issues can be found in Bugzilla: https://bz.apache.org/bugzilla 50213: Category callAppenders synchronization causes java.lang.Thread.State: BLOCKED 46878: Deadlock in 1.2.15 caused by AsyncAppender and ThrowableInformation classes 41214: Deadlock with RollingFileAppender 44700: Log4J locks rolled log files (files can’t be deleted) 49481: Log4j stops writing to file, and then causes server to lockup 50323: Vulnerability in NTEventLogAppender 50463: AsyncAppender causing deadlock when dispatcher thread dies 50858: Classloader leak when using Log4j in a webapp container such as Tomcat, WebLogic 52141: [STUCK] ExecuteThread...Blocked trying to get lock: org/apache/log4j/Logger@0xc501e0a8[fat lock] 54009: Thread is getting Blocked 54325: Concurrency issues in AppenderAttachableImpl * Complexities with Log4j 1 build system that could impact binary compatibility Apart from the issues listed above, Log4j 1 suffers from a challenging build system designed around long outdated versions of Java and operating system specific Appenders that the current development team cannot support. Taking shortcuts in proposed fixes means an updated release would not support all the environments of the original 1.2.x release. Patches to Log4j 1 would also have to be compatible with the existing Log4j 2 migration path. * Limited Log4j 1 community The Apache Logging PMC and committer community has been focused on the success of Log4j 2 for nearly a decade. There had been little to no interest in Log4j 1 in the years leading up to the 2015 EOL announcement. While there might be people interested in working independently on Log4j 1, until the Logging Services community can gauge the merit of those contributors, the PMC would have to review and apply all patches, drive the release process, and provide future support. We feel that effort is better spent improving non-legacy code. We welcome community contributions in the migration components for better tooling and support. Regards, Ron -- The Apache Software Foundation V.P., Logging Services --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
