commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Thu, 24 Mar 2005 23:50:45 GMT
On Thu, 24 Mar 2005 14:37:28 -0500, Yoav Shapira <> wrote:
> Hi,
> Over on the log4j mailing list, we've been discussing an interesting idea
> for the next-generation commons-logging-type component, and wanted to run
> the idea by the commons-dev crew for feedback.  This is just informal at
> this point, soliciting opinions.
> First, as background:
> -          Jakarta Commons Logging (JCL) has some problems, as discussed in
> and
> <> &r=1&w=2
> many other problems.
> -          The log4j team has developed UGLI
> ( to solve these problems,
> following a good amount of thought and discussion
> -          UGLI is new and very few people know about it, while JCL is very
> familiar and widely used
> I (personally, not speaking for the entire log4j team here) think it would
> be a lot easier for UGLI to be adopted if it is essentially called JCL 2.0
> or better yet, commons-logging 2.0 (CL2), taking advantage of that brand
> name instead of throwing a completely new and unfamiliar, "yet another
> logging interface" to the users.  So I wanted to ask: what would the commons
> development community, especially those working on commons-logging, think
> of:
> -          Move the commons-logging project out of jakarta, into its own
> project in Logging Services
> -          Proactively cooperate with the log4j team, commons-logging team,
> and other interesting parties (e.g. Tomcat, so I'm wearing about three
> different hats when writing this message), to combine JCL 2.0 intended
> features with current UGLI features
> Comments?

At this point, the only productive thing that could happen is if log4j
adopted the java.util.logging API as the logging API for
The java.util.logging API, wether you guys accept it or not, is the
only realistic standard moving forward. That way, we would not be
needing any "wrapper API" gimmick, and applications could use the full
logging APIs rather than being limited to a small subset of its

One big thing you'll have to understand: I do not and will not change
the API yet again (so anything "new" provided will have to be source
and binary compatible). I'm just tired of logging problems.

As a personal note, I find this proposal completely out of place after
years of FUDing and dissing commons-logging in general, and anything
not log4j in particular.

Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message