From time to time I have come across comments asking the very question posed above. Why another logging framework when SLF4J and Logback already exist? For those who are curious, here is the answer.
I started working for Candle Corporation in 1984 where I spent a lot of time developing in C writing code that would make Candle's performance monitoring applications portable to a wide variety of operating systems. One of the components we created was a logging framework. When I went to work for Digital Insight in 2001 I was tasked with helping to migrate their applications from C and C++ to Java.
Digital Insight provides internet banking for smaller banks and credit unions so, of course, one of the first frameworks needed was for logging. At that time virtually the only logging solution available was Log4j 1. I evaluated it but quickly determined it would be difficult to support multi-tenant applications with it, so I ended up writing my own that we used for a while. When Java 1.4 was released I looked at java.util.logging and determined it was worse than Log4j. Work progressed on converting the internet banking system to Java and as time went by I kept looking for a better logging solution.
In 2007 I saw that SLF4J and Logback had been developed and could now be used for multi-tenant applications. However, since I was working for a company that was essentially a bank we had a need to perform audit logging where events could not be lost and logging events could contain multiple attributes, not just strings. I provided a few bug fixes to SLF4J and Logback that were accepted but the more critical pieces, like SLF4J-139, LOGBACK-588, and SLF4J-281 were not and are still open today. Also, a critical performance problem we found in SLF4J-240 hit us hard and wasn't fixed until 2017, 6 years after it was opened. Given the lack of response on these issues, when I discovered that Logback loses logging events whenever a reconfiguration takes place I knew I had to find another alternative.
In 2003 I started to become involved with Apache Cocoon as well as working on open source software and then became involved with Apache Commons. I became a member of the Apache Software Foundation in 2007 and got involved in more projects after that. So when I had to make a decision as to how to deal with the issues I was having with SLF4J it seemed natural to work within a project at the ASF.
Unfortunately, the work on Log4j 1.x had pretty much come to a standstill after Ceki left to start SLF4J and Logback and most of the committers had stopped participating. So I worked for several months creating the foundation of Log4j 2 in late 2009 and early 2010 and then committed the code to the ASF's subversion repository on an experimental branch in the hopes that it would attract other contributors. It did.
I had focused on preserving the things I liked about Log4j 1, SLF4J, and Logback but fixing the things I didn't. Namely, I had always disliked that every component in a logging configuration had to name the class that implemented it. I needed to address having a more flexible approach to what was being logged and so introduced logging Messages to the API. And lastly, I had to fix the problem with losing events during configuration so I separated Loggers from their configuration. I also addressed locking issues that were present in both Log4j 1.x and Logback.
Once I committed the first code others joined. What I really like about the Apache model is that anyone who has good ideas and free time can become a committer, and once you are committer your ideas and opinions are equal to all other committers. Some of the best ideas were introduced by the people who joined to help contribute to Log4j 2. Using the annotation processor to improve plugin loading and the idea of using the LMAX Disruptor to implement asynchronous Loggers were just two of the outstanding improvements that were added by others.
Two years after the first public commit we made our first alpha release of Log4j 2 and then spent another 2 years before we felt it was ready for general availability. In the years since many other new features have been added and we will continue to innovate to provide features that are important to users. However, we always want to encourage new people to contribute. Some of the best ideas (and code) often come from people who are new to the project.