Hello Ceki On Thu, Jan 6, 2022, at 11:00, Ceki Gülcü wrote: > The fact that the decision was unanimous on such a delicate matter is > quite surprising and very interesting in itself with respect to group > dynamics.
You haven't been at the meeting. That's why you don't know anything about this group or its "dynamics". > Coming back to the issue at hand, the notion that log4j 2.x offers a > natural migration path from log4j 1.x is rather doubtful. Why is that? There is docs and we haven't received many problems with the migration so far. I made such migrations several times myself. I found them pretty straight forward. > As for the various log4j 1.x bugs, log4j 2.x also has numerous bugs and > some of the design choices in 2.x are very much debatable. Log4j 2 is not what we discussed. If you want to discuss log 4j 2, make your suggestions in another thread on the dev list. > More practically speaking, I think it is important to fix the critical > issues in log4j 1.x. The effort involved is reasonable and is likely to > help a lot of people. Which ones? The JMSAppender issue or the SockerServer issue? Both have been there >2012. What is suddenly so critical it requires re-releasing EOL software? Or did you mean the multithreading issues? However, if you want to see that fixed, you can help. You are still a committer to ASF logging and member to this foundation. If you like, you can mentor the two potential contributors, review and apply the patches. You could also craft the 1.2.18 release and put it up for a vote. Have a happy new year too! Kind regards, Christian > Best regards and a happy new year. > > -- > Ceki Gülcü > > Please contact suppport(at)qos.ch for donations, sponsorship or support > contracts related to SLF4J or logback projects. > > > > On 06/01/2022 01:23, Ron Grabowski wrote: >> 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
