This release contains the first support of Java 9 as well as bugfixes and minor
enhancements. The Log4j API was modified to use java.util.ServiceLoader to locate Log4j implementations,
although the former binding mechanism is still supported. The Log4j jar is now a multi-release jar
to provide implementations of the 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 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.

The Apache Log4j 2 team is pleased to announce the Log4j 2.8 release!
This release contains several bugfixes and new features. The new features include the ability
to have the RollingFileAppender log directly to the archive files,
a new Apache Cassandra appender,
a new ThreadContext::getThreadContextMap API method for custom ThreadContext implementations,
support for variables in GelfLayout's additional fields, and
support for Lookups in properties' default values.
Also, this release continues the GC-free epic by updating many more filters and pattern layout
converters so that they no longer allocate temporary objects during steady state logging.
More details on the new features and fixes are itemized below.
[Read More]

The Apache Log4j 2 team is pleased to announce the Log4j 2.7 release! This release contains several bugfixes and new features. The new features include new logging API modules for Scala 2.10 and 2.11, and support for various non-blocking queue implementations in
AsyncAppender. Furthermore the ThreadContext map can now be configured to be garbage-free, and
users can now inject context data from other sources than ThreadContext. Context data values can
be any Object, not just Strings.[Read More]

Log4j 2.7 will be released in a few days. The community is now reviewing the site and the artifacts for any last minute showstopper. Meanwhile, you may be interested in a sneak peek into what is coming.

Did you know that Log4j 2 is nominated for the JAX Innovation Awards?
Vote for Log4j 2 if you like its performance, garbage-free logging, and easy and flexible configuration! Voting closes September 29th, 2016.

This is a general call-to-arms for everyone who uses log4net as their
logging solution. If log4net is the logging framework that you are
using and would like to keep using in the future it is time now to get
involved. The project needs a larger developing community to move on!
We really need more people who want to shape the future of log4net at
the Apache Software Foundation.

In all the time since log4net has been started by Nicko Cadell more
than ten years ago, there have never been more than two or three
people regularly contributing to it. As is normal in open source
projects people have come and gone when their interests or just the
amount of time they could invest have changed.

At the moment Dominik Psenner and Stefan Bodewig are the only people
semi-actively working on log4net and neither of them is able to devote
as much time to the project as they'd like to and as would be
required.

Realistically log4net is maintenance mode where development of new
features is not going to happen.

This has repeatedly made log4net lag behind recent developments in the
.NET world. It took a long time to get a version out that properly
worked with .NET 4.0 in 2011 and adaptions to .NET 4.5 also took much
longer than many users would have wished. We are seeing it again with
.NET Core right now. In addition there are many unresolved issues in
log4net's JIRA.

Despite this there are more than 2500 downloads of the logging
framework every day from nuget. We are asking you, the log4net
community, to get your hands dirty.

Right now we are in the process of creating a log4net release that
works for .NET Core. It is a very targeted effort and it is very
unlikely Dominik and Stefan will be able to contribute more in the
future than we did during the past months.

If you are willing to help, please join log4net's dev mailing list and
raise your hand. Look through log4net's issue tracker and pick things
you'd like to work on. If you don't know where to start, please ask,
Dominik and Stefan will be there to help.

If there is anything holding you back from contributing, let's discuss
it and get it out of the way. Nothing is carved into stone, neither
what the future of log4net holds nor how we make it happen.

Log4j 1 has had a good run. First released in 1999, it is still widely used in a variety of Java-based projects. With Java 9, that is likely to come to an end: Log4j 1.2 is broken on Java 9. Essentially the MDC depends on the Java version string, which does not play well with Java 9's new version-string format.

To any project that is interested in running on Java 9, I'd strongly recommend migrating to Log4j 2 now.

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.
[Read More]

We are very happy that Nick Williams joined the Apache Logging Services PMC. He is involved mainly in the development of Log4j 2.0 but also keeps an eye on Log4cxx. Thanks Nick for all what you did so far and all the best for you new role at Apache Logging.

The Apache Log4j 2 team is proud to announce the Log4j 2.0-rc1 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 of the improvements available in Logback while fixing some inherent problems in Logback's architecture.

This is the twelfth release and first release candidate of Log4j 2 and is being made available to encourage use and feedback from the community. Rapid feedback is especially critical at this point since a general availability release is on the horizon.

Bug fixes and enhancements

This release contains several changes that break binary and backwards compatibility
with previous versions. Please read the release notes correctly so that you
can adjust your usage of Log4j 2, if necessary.

LOG4J2-512: Exposed Log4j web support interface and methods and the LoggerContext through ServletContext attributes so that threads not affected by filters (such as asynchronous threads) can utilize the LoggerContext. Also updated the Log4j filter so that it supports async. Thanks to Chandra Sekhar Kakarla, Matt Sicker.

LOG4J2-409: Created a utility to properly escape backslashes before creating URIs, and changed URI creation to use the utility instead of instantiating URI directly. Thanks to Frank Steinmann, Thomas Neidhart.

LOG4J2-344: Changed the Servlet 3.0 auto-initializer to add the filter by class to get around a WebLogic bug. Thanks to Keir Lawson, Tomasz Wladzinski.

LOG4J2-359: Changed the Servlet 3.0 auto-initializer so that it does nothing in a Servlet 2.5 or older application. This ensures behavioral consistency across containers. This includes additional fixes to abort initialization if a duplicate filter already exists and to check the actual Servlet EFFECTIVE version. Thanks to Abhinav Shah.

LOG4J2-517: Switch in log4j-1.2-api Category.getEffectiveLevel has no cases for FATAL, OFF.

LOG4J2-406: (JMX) Unregister all log4j JMX MBeans when the LoggerContext is stopped to allow web application classes to be GC-ed on undeploy. Thanks to Kerrigan Joseph.

LOG4J2-532: Resource leak in Flume appender when it cannot create a BerkeleyDB db.

Apache Log4j 2.0-rc1 requires a minimum of Java 6 to build and run. 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 group ID 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: