logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject Re: log4j-2.0 questions
Date Tue, 21 Jun 2011 00:04:50 GMT

On Jun 20, 2011, at 17:33, "ralph.goers @dslextreme.com" <ralph.goers@dslextreme.com<mailto:ralph.goers@dslextreme.com>>

Hey Mark, thanks for participating in this!  See my comments inline below.

On Mon, Jun 20, 2011 at 12:22 PM, Mark Struberg <<mailto:struberg@yahoo.de>struberg@yahoo.de<mailto:struberg@yahoo.de>>
Hi folks!

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

How close is the code to something close to a beta?

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

How much work us that?


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

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.


To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message