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

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

On Mon, Jun 20, 2011 at 12:22 PM, Mark Struberg 
<<mailto:strub...@yahoo.de>strub...@yahoo.de<mailto:strub...@yahoo.de>> wrote:
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 welcome.


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 this.

How much work us that?

Gary



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.

Ralph

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

Reply via email to