logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: JDJ - log4j vs java.util.logging
Date Fri, 25 Mar 2005 10:31:20 GMT
Hi All,

I´m a commons committer and have been involved in the recent 
commons-logging work going on there. I thought you might be interested 
in a view of this topic from "the other side of the fence". Note, 
however, that I am speaking only for myself in the rest of the email.

It is accepted that people have problems using commons-logging, and 
generally accepted (though not yet 100% proved) that fixing these 
problems will require significant change to the existing commons-logging 
implementation (though *hopefully not* the user API). A significant 
amount of work is going on right now on the commons lists to investigate 
the issues and look at possible solutions.

Simply adopting the UGLI approach is one possibility. However it is 
becoming clear that the issues surrounding logging in j2ee-style apps 
are quite complicated; before adopting a radically different solution we 
all need to be sure we understand all the issues, and don´t leap from 
one incorrect solution to another. Ceki´s very confrontational tone 
hasn´t helped the case; while I respect Ceci´s technical ability very 
much some of the information in articles written by him about the 
existing commons-logging is just plain wrong, and intended to persuade 
users to jump ship rather than provide a fair evaluation. We (jcl 
maintainers) need to thoroughly understand jcl, ugli and all the user 
requirements before making a final choice - and this is what is in 
progress right now. Jacob´s tone has been similar. Guys: there *isn´t* 
any ego or "not invented here" reason for failing to jump immediately to 
using UGLI; it´s that we need to be sure UGLI is the right solution 
first and no amount of yelling at us or calling us fools will make us 
decide to make that leap without doing the necessary research first. 
Well-balanced and reasonable discussion, on the other hand, is very much 

The reason for the existence of commons-logging is that the commons 
projects need a logging API that they can use. I´m personally neutral on 
whether that API should be maintained via a project under the 
apache-jakarta-commons umbrella or the apache-logging umbrella. Having 
it under commons does, however, emphasise its platform-neutral status 
better than having it managed by the same team responsible for providing 
one of the implementations it wraps. Whether it is in jcl´s best 
interests for the owing project to be specialist (apache-logging) or 
generalist (commons) is up for debate; both have pros and cons.

I don´t think anyone working on commons-logging really cares about 
"branding" or "market share". Commons-logging exists because it solves a 
problem that the other commons projects faced: the commons libraries 
need to log stuff to help users diagnose issues, but can´t bind to a 
specific logging implementation because the code using the library may 
want to use a different implementation. If others find it useful in 
their libraries (or even non-library code) then that´s nice but JCL is 
not trying to take over the world, so naming isn´t that important, nor 
is which umbrella project the code lives under.

Note, by the way, that commons-logging existed well before log4j became 
an apache project, and a long time before the "apache logging" umbrella 
project was created. You might also note that I was providing (minor) 
patches to log4j well before I got involved with commons.

Regarding "yet another logging interace", I don´t think this is an 
issue. There are no major problems with the existing API for use by user 
code as far as I am aware. There are two proposed extensions to this 
interface (i18n, and allowing message interpolation of form "Error {0} 
occurred in {1}"). However these would seem to fit nicely as extensions 
to the existing api rather than replacements of it. There will almost 
certainly be a change to the API used when writing adaptors from JCL to 
concrete logging implementations, but that´s no big deal. The only issue 
is that if jcl moves, then the package name "org.apache.commons.logging" 
will need to change, causing wide-spread (though trivial) changes to 
code using JCL.

I would think that consensus on what will happen to JCL is likely to be 
reached within the next 3 months, given the progress made over the last 
month or two.

Again, I would like to restate that all of this is my personal view 
only, as one (but not the most important) of the commons committers 
working on commons-logging.



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

View raw message