As recently published in InfoQ, the Apache Software Foundation announced the end of life of version 1 of Log4j, encouraging users to upgrade to version 2 of the popular logging framework.
InfoQ reached out to the following members of the Apache Logging Services Team to find out more about the transition to the new version of Log4j and about its future: Ralph Goers, member of the Apache Logging PMC and initiator of the Log4j 2 initiative, Remko Popma and Gary Gregory, both also members of the Apache Logging PMC, and Christian Grobmeier, Apache Logging Chair.
InfoQ: Despite Log4j2 being available for just over a year, according to maven central statistics, version 1 is still much more popular than version 2. Do you think the EOL will motivate users to migrate to the new version?
Remko: I hope that the EOL will at least raise awareness that Log4j 2 exists. I fully understand that sometimes there is little incentive to change something that has not caused any issues, but I do hope that the EOL will stimulate people to use Log4j 2 at least for new projects.
Christian: EOL is maybe just a label, but we all know how unlikely it is that anybody else will ever invest a lot of time to make a new Log4j 1 release. The build is horribly complicated. As there will not be any releases, this may also cause security concerns for some. Actually we have a full Log4j 1 bugtracker where people are still free to report issues, we just won’t fix them unless a patch is provided. This means that people should consider upgrading if only for security reasons.
InfoQ: It seems the main reason to rewrite Log4j in a new version was to overcome a number of architectural challenges present in version 1. However, there may be a number of users with simple logging needs that may not need the new features being developed, what would you tell these users to convince them to migrate to version 2?
Remko: "Simple logging needs" often means "we're busy and don't have time to analyse our future logging needs or spend time on comparing options". Totally understandable. I'd say Log4j 2 is a perfect choice: it is easy to use, screaming fast and has an incredible depth of features and flexibility if your needs grow in the future.
Ralph: While we are recommending users upgrade to Log4j 2 they are certainly free to stick with Log4j 1 as long as they wish. However, users should know that, although they can still report any problems they encounter with Log4j 1, they will only be fixed if they provide the patches or can find others who will.
Gary: A point obvious to all of us (developers) but not to all (users) is that we are all volunteers, which means we have a limited amount of time and resources and therefore need to decide what’s the most efficient way to dedicate those resources. Making changes in Log4j 1 is too hard, we can get more value by focusing the same amount of effort in version 2.
Another is that the EOL are just words. If people step up, a release can happen. But some issues could only be easily addressed in a new architecture and version.
InfoQ: Having to stop using Log4j version 1, a number of developers may consider migrating to a different logging framework as opposed to simply upgrading to version 2, is this a concern?
Remko: I strongly feel Log4j 2 is competitive against the other choices, and these are some of the features of Log4j 2 that I would highlight to justify that:
- Community support: Log4j 2 has an active community where questions are answered, features are added and bugs are fixed.
- Ultra-low performance impact: Asynchronous Loggers provide a level of performance similar to having logging completely switched off.
- Stability/reliability: Automatically reload configuration upon modification without losing log events while reconfiguring.
- Rich feature set including Custom log levels, Filtering (based on context data, markers, regular expressions, and other components in the Log event) and Lookups.
- Plugin Architecture: easy to extend by building custom components.
- Supported APIs: Log4j 2 can be used directly or through SLF4J, Commons Logging, Log4j 1 and java.util.logging.
- Java 8 lambda support in the upcoming 2.4 release.
InfoQ: Do you think the timing for the EOL of Log4j version 1 was right? If you could change it, would you do it sooner, later or same?
Remko: I think it was right. Log4j 2 has had 19 releases thus far, the last six being marked as General Availability. It has been more than a year since the first GA release, and Log4j 2 has proven to be extremely stable. This makes us think Log4j 2 is a safe replacement for Log4j 1, and therefore it’s a good moment to declare the end of the previous version.
Ralph: Our statement regarding the end of life was simply an admission of the reality that no one was working on fixing bugs in Log4j 1 and hadn't been for years; in a way, version 1 had reached its EOL long ago. We just needed to make sure Log4j 2 was a stable, credible replacement before officially retiring Log4j 1.
InfoQ: What do you think are going to be the main challenges in the area of logging? And specifically for Log4j?
Remko: Personally, I would like to continue to improve Log4j 2's performance, especially in synchronous logging scenarios. I think there are still a lot of improvements possible in that area. A bigger picture challenge is probably log management: collection, centralised aggregation, long-term retention, log analysis, log search and reporting. There are products that try to solve these issues, and perhaps if standards emerge Log4j can do things to help make these tasks easier.
The Apache Software Foundation has created a migration guide for users who wish to upgrade from version 1 to version 2, and a summary of Log4j 2’s features to recommend its adoption.