Apache Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, andprovides many of the improvements available in Logback while fixing some inherent problems in Logback's architecture.
Important: Security Vulnerability CVE-2021-44832
Summary: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.
Details
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable toa remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file canconstruct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can executeremote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1,2.12.4, and 2.3.2.
Mitigation
Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later)
Reference
Please refer to the Security page for details and mitigation measures for olderversions of Log4j.
Important: Security Vulnerabilities CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228
Please refer to the Security page for details and mitigation measures for these security issues.
Features
API Separation
The API for Log4j is separate from the implementation making it clear for application developers which classes andmethods they can use while ensuring forward compatibility. This allows the Log4j team to improve the implementationsafely and in a compatible manner.
The Log4j API is a logging facade that may, of course, be used with the Log4j implementation, but may also be usedin front of other logging implementations such as Logback. The Log4j API has several advantages over SLF4J:
- The Log4j API supports logging Messages instead of just Strings.
- The Log4j API supports lambda expressions.
- The Log4j API provides many more logging methods than SLF4J.
- In addition to the “parameterized logging” format supported by SLF4J, the Log4j API also supports events usingthe java.text.MessageFormat syntax as well printf-style messages.
- The Log4j API provides a LogManager.shutdown() method. The underlying logging implementation must implement theTerminable interface for the method to have effect.
- Other constructs such as Markers, log Levels, and ThreadContext (aka MDC) are fully supported.
Improved Performance
Log4j 2 contains next-generation Asynchronous Loggers based on the LMAX Disruptor library. In multi-threaded scenariosAsynchronous Loggers have 18 times higher throughput and orders of magnitude lower latency than Log4j 1.x and Logback.See Asynchronous Logging Performance for details. Otherwise, Log4j 2 significantlyoutperforms Log4j 1.x, Logback and java.util.logging, especially in multi-threaded applications.See Performance for more information.
Support for multiple APIs
While the Log4j 2 API will provide the best performance, Log4j 2 provides support for the Log4j 1.2, SLF4J, CommonsLogging and java.util.logging (JUL) APIs.
Avoid lock-in
Applications coded to the Log4j 2 API always have the option to use any SLF4J-compliant library as their loggerimplementation with the log4j-to-slf4j adapter.
Automatic Reloading of Configurations
Like Logback, Log4j 2 can automatically reload its configuration upon modification. Unlike Logback, it will do sowithout losing log events while reconfiguration is taking place.
Advanced Filtering
Like Logback, Log4j 2 supports filtering based on context data, markers, regular expressions, and other components inthe Log event. Filtering can be specified to apply to all events before being passed to Loggers or as they pass throughAppenders. In addition, filters can also be associated with Loggers. Unlike Logback, you can use a common Filter classin any of these circ*mstances.
Plugin Architecture
Log4j uses the plugin pattern to configure components. As such, you do not need to write code to create and configure anAppender, Layout, Pattern Converter, and so on. Log4j automatically recognizes plugins and uses them when aconfiguration references them.
Property Support
You can reference properties in a configuration, Log4j will directly replace them, or Log4j will pass them to anunderlying component that will dynamically resolve them. Properties come from values defined in the configuration file,system properties, environment variables, the ThreadContext Map, and data present in the event. Users can furthercustomize the property providers by adding their own Lookup Plugin.
Java 8 Lambda Support
Previously, if a log message was expensive to construct, you would often explicitly check if the requested log level isenabled before constructing the message. Client code running on Java 8 can benefit from Log4j'slambda support. Since Log4j will not evaluate a lambda expression if the requested loglevel is not enabled, the same effect can be achieved with less code.
Custom Log Levels
In Log4j 2, custom log levels can easily be defined in code or in configuration. Nosubclassing is required.
Log Builder API
In addition to using one of the many log methods in the Log4j API, log events can be constructed using a builder. SeeLog Builder for more information.
Garbage-free
During steady state logging, Log4j 2 is garbage-free in stand-alone applications, and lowgarbage in web applications. This reduces pressure on the garbage collector and can give better response time performance.
Integrating with Application Servers
Version 2.10.0 added the module log4j-appserver to improve integration with Apache Tomcat and Eclipse Jetty.
Cloud Enabled
Version 2.12.0 introduced support for accessing Docker container information via a Lookup and for accessingand updating the Log4j configuration through Spring Cloud Configuration. This support was enhanced inversion 2.13.0 to add support for accessing Spring Boot properties as well as Kubernetes information.See Logging in the Cloud for details.
Compatible with Log4j 1.x
The Log4j-1.2-api module of Log4j 2 provides compatibility for applications using the Log4j 1 logging methods. Asof Log4j 2.13.0 Log4j 2 also provides experimental support for Log4j 1.x configuration files. SeeLog4j 2 Compatibility with Log4j 1 for more information.
Documentation
The Log4j 2 User's Guide is available on this site.
Requirements
Log4j 2.13.0 and greater require Java 8. Version 2.4 through 2.12.1 required Java 7 (the Log4j team no longer supportsJava 7). Some features require optional dependencies; the documentation for these features will specify the requireddependencies.
News
Log4j 2.17.2 has been released to:
- Over 50 improvements and fixes to the Log4j 1.x support. Continued testing has shown it is a suitable replacementfor Log4j 1.x in most cases.
- Scripting now requires a system property be specified naming the languages the user wishes to allow. The scriptingengine will not load if the property isn't set.
- By default, the only remote protocol allowed for loading configuration files is HTTPS. Users can specify a systemproperty to allow others or prevent remote loading entirely.
- Variable resolution has been modified so that only properties defined as properties in the configuration file can berecursive. All other Lookups are now non-recursive. This addresses issues users were having resolving lookups specifiedin property definitions for use in the RoutingAppender and RollingFileAppender due to restrictions put in place in 2.17.1.
- Many other fixes and improvements.
2.17.2 (for Java 8) is a recommended upgrade.
Log4j 2.21.0 is now available for production. While the normal API for Log4j 2 is not compatible withLog4j 1.x, an adapter is available to allow applications to continue to use the Log4j 1.x API and configuration files.Adapters are also available for Apache Commons Logging, SLF4J, and java.util.logging.
Log4j 2.21.0 is the latest release of Log4j. As of Log4j 2.13.0 Log4j 2 requires Java 8 or greater atruntime.This release contains new features and fixes which are explained further in release notes.
Log4j 2.21.0 maintains binary compatibility with previous releases.
