Hey Mark, thanks for participating in this! See my comments inline below.
On Mon, Jun 20, 2011 at 12:22 PM, Mark Struberg <email@example.com>
My name is Mark and I had a few discussions about log4j 2.0 with Ralph lately. It is about the question whether log4j-2.0 would be a candidate for all the internal logging of Apache Maven or not.
I've checked out the sources they build fine. I'm not a logging expert, but more a casual programmer, so please excuse any dumb questions:
First, there are no dumb questions and even if there were these aren't. Second, as you can tell from where it is located this has not yet been accepted as the official Log4j 2.0. It is something I've been working on for over a year in the hopes that it will become that, but that won't happen without the kinds of scrutiny and questions you are asking so they are most welcome.
1.) is the logging implementation pluggable?
How do you mean "pluggable"? Legacy Log4j is "pluggable" in that you can specify your own classes of things in the configuration. That said, the new implementation no longer requires class names being declared in the configuration and instead uses annotations to locate pluggable elements. It is also designed so that the API is distinctly separate from the implementation, much like SLF4J. As you should be able to tell I've also made the implementation callable using any of the Log4j 1.2, SLF4J, or Commons Logging APIs.
2.) is there an optional support for ThreadContextClassLoader scenarios?
This is often a problem for logging in libraries which are on a shared classpath. Imagine 2 webapps, both using OpenWebBeans as CDI container. One webapp sets the org.apache.webbeans loglevel to debug, the other wone to WARN ...
As it currently stands, no, but I have always intended to introduce something to support that.
When I wrote the Log4j 2 API it took a stab at creating an abstraction to bind the API to an implementation. It was only when I built the core that I added the plugin support. Looking at how it is done it now occurs to me that the plugin support really should move to the API and be used to bind to the implementation. This would provide the flexibility needed to accomplish this.
3.) I've seen that the API now uses ellipsis parameters. Wouldn't it be better to re-position the Throwable parameter before the String parameter? Otherwise that might interfere with the Object... parameter, isn't?
One advantage of leaving the throwable at the end is that it makes it more compatible with existing APIs. For example, if you look at the Commons Logging adapter you will notice that Log4JLog.java has no methods in it as they all come from the Log4J 2 API. Moving the params would also make it more difficult to match the SLF4J API since it does not do what you are suggesting.
There are two cases here. In the first the method signature includes a Throwable. In that case it is unambiguous and is handled properly. In the second case, Joern Huxhorn provided the ParameterizedMessage class that detects that the last Object in the array is a Throwable and handles it. However, there is an oddity that in some cases the Throwable appears in the ParameterizedMessage isn't propagated to the LogEvent correctly. I'll create a test for that and fix it.
I'd certainly consider a change to this if you would like to wade in and give it a shot. :-)
4.) How much work is left to do before you could perform a first 'teaser release'? For starting with using log4j we would at least need anything which got released.
I've been hacking away on it pretty much on my own trying to add a little bit more of what is missing from Log4J 1.2 every day.I have most of the Filters, Layouts and Appenders although the DBAppender is still not there. It also doesn't have JMX support yet. At work we are also using Flume so I'm thinking I will want to add an Appender to work with it.
That said, this is the first real discussion of Log4J 2.0 in a year or so.