\r\nThe Apache Log4j 2 team is pleased to announce the Log4j 2.10 release!\r\n
\r\n\r\nApache Log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many other modern features such as support for Markers, lambda expressions for lazy logging, property substitution using Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another notable Log4j 2 feature is the ability to be \"garbage-free\" (avoid allocating temporary objects) while logging. In addition, Log4j 2 will not lose events while reconfiguring.\r\n
\r\n\r\nThis release contains new features, bugfixes and minor enhancements. Some of the new features include support for the Java 9 module system, support for the new SLF4j 1.8 binding mechanism, simplification of the Log4j property naming scheme, and native support of Jetty's logger. Log4j API is now a fully compliant Java 9 module while the other Log4j jars are Java 9 named automatic modules.\r\n
\r\n\r\nThis release supports both SLF4J 1.7.x and SLF4J 1.8.x. Because SLF4J 1.7.x requires implementations to include classes in the org.slf4j.impl package log4j-sl4j-impl cannot be used as a Java 9 module. Support for SLF4J 1.7.x will be removed in a future release.\r\n
\r\n\r\nAs of Log4j 2.9.0, the Log4j API was modified to use java.util.ServiceLoader to locate Log4j implementations, although the former binding mechanism is still supported. The Log4j API jar is now a multi-release jar to provide implementations of Java 9 specific classes. Multi-release jars are not supported by the OSGi specification so OSGi modules will not be able to take advantage of these implementations but will not lose functionality as they will fall back to the implementations used in Java 7 and 8. More details on the new features and fixes are itemized below. Note that some tools are not compatible with multi-release jars and may fail trying to process class files in the META-INF/versions/9 folder. Those errors should be reported to the tool vendor.\r\n
\r\n\r\nDuring testing
of the release it was found that one unit test fails when run on Windows. When building
from source either use “mvn clean install -DskipTests” on Windows or
run the build on a different operating system. The unit test failure is a problem
in the test, not in Log4j. As always, pre-built distributions can be downloaded
from http://www.apache.org/dist/logging/log4j/ or the binaries jars may be obtained
from the Maven central repository.\r\n
The Apache Log4j 2 team is pleased to announce the Log4j 2.10 release!
Apache Log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many other modern features such as support for Markers, lambda expressions for lazy logging, property substitution using Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating temporary objects) while logging. In addition, Log4j 2 will not lose events while reconfiguring.
This release contains new features, bugfixes and minor enhancements. Some of the new features include support for the Java 9 module system, support for the new SLF4j 1.8 binding mechanism, simplification of the Log4j property naming scheme, and native support of Jetty's logger. Log4j API is now a fully compliant Java 9 module while the other Log4j jars are Java 9 named automatic modules.
This release supports both SLF4J 1.7.x and SLF4J 1.8.x. Because SLF4J 1.7.x requires implementations to include classes in the org.slf4j.impl package log4j-sl4j-impl cannot be used as a Java 9 module. Support for SLF4J 1.7.x will be removed in a future release.
As of Log4j 2.9.0, the Log4j API was modified to use java.util.ServiceLoader to locate Log4j implementations, although the former binding mechanism is still supported. The Log4j API jar is now a multi-release jar to provide implementations of Java 9 specific classes. Multi-release jars are not supported by the OSGi specification so OSGi modules will not be able to take advantage of these implementations but will not lose functionality as they will fall back to the implementations used in Java 7 and 8. More details on the new features and fixes are itemized below. Note that some tools are not compatible with multi-release jars and may fail trying to process class files in the META-INF/versions/9 folder. Those errors should be reported to the tool vendor.
During testing of the release it was found that one unit test fails when run on Windows. When building from source either use “mvn clean install -DskipTests” on Windows or run the build on a different operating system. The unit test failure is a problem in the test, not in Log4j. As always, pre-built distributions can be downloaded from http://www.apache.org/dist/logging/log4j/ or the binaries jars may be obtained from the Maven central repository.
Note that subsequent to the 2.9 release, for security reasons, SerializedLayout is deprecated and no
longer used as default in the Socket and JMS appenders. SerializedLayout can still be used as before,
but has to be specified explicitly. To retain old behaviour, you have to change configuration like:
into:
We do, however, discourage the use of SerializedLayout and recommend JsonLayout as a replacement:
Note that subsequent to the 2.9 release, for security reasons, Log4j does not process DTD in XML files.
If you used DTD for including snippets, you have to use XInclude or Composite Configuration instead.
The Log4j 2.10.0 API, as well as many core components, maintains binary compatibility with previous releases.
Changes in this version include:
Apache Log4j 2.10.0 requires a minimum of Java 7 to build and run. Log4j 2.3 was the last release that supported Java 6.
Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api component, however it does not implement some of the very implementation specific classes and methods. The package names and Maven groupId have been changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
For complete information on Apache Log4j 2, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Apache Log4j 2 website: