commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] proposal
Date Wed, 03 Aug 2005 22:18:16 GMT
On Wed, 2005-08-03 at 00:51 +0200, joerg wrote:


> just to get it right:
> Is JCL = Jakarta Commons Logging?


> lf4j is the "Simple Logging Facade for Java"
> and ceki the founder and they have
> which is very similar to

there's quite a bit more history than that. it's continuation of the
log4j work to create a second generation bridging API. it was moved
outside apache for licensing issues (to allow greater participation).
ceki does all the commits (it was moved outside apache for licensing
issues) but there are lot of folks on the list who are experts on
logging frameworks and bridges. for slf4j to succeed, it need to carry
the support of those folks and so stuff mostly happens by consensus.

> slf4j seems to have two loglevels less than commons-logging (trace and
> fatal). I personaly would miss these levels a lot!

ceki has his own theories about logging frameworks and i think he's
proved that he's entitled to them. i'm pretty sure that if someone could
provide a rational argument for including them, he'd add them. it's an
open list so why not sign up and post your use cases!

(a lot time dealing with logging bridges is spend analysing and
discussing use cases rather than coding)

> Hope thats all correct.
> Anyways your suggestion was to bring the ideas of both projects together
> and have one Log(ger) interface (and maybe do not waste performance by
> adapters), is that correct? Maybe there was a lot more behind this but I
> am not too deep in that to get it.

not quite

the time is ripe for a second generation bridging API. however, IMHO one
of the major faults with all of the first generation ones were that they
were implementations rather than specifications. JCL is hamstrung by
backwards compatibility issues which it would never have had if users
had coded to a specification rather than a concrete implementation.

IMHO i'm not sure that any of the candidates will succeed without the
support of the major players. these includes ceki (and so and JCL. i don't have the energy to push a dominant
second generation solution (and i'm not sure whether any of the other
JCL folks do either) but would like to see one emerge. 


> I would not mind involving the slf4j community but cross-discussions on
> different mailing lists is not to easy to track and I would not like to
> loose the focus on this one.
> But I will subscribe to slf4j list and invite them to come into this
> discussion. Does that somehow match a little of your intention.
> (I better wait for response).

waiting was probably a good idea :)

issuing an invitation to the list wasn't what i'd intended...

the slf4j list has proved to be a better neutral ground (between
licensing paradigms and framework approaches as well as logging systems)
than this list. i suggested it because i'd be interested to hear what
the people on that list would make of your API suggestions and thought
you'd find it interesting to fence a little with them...

- robert

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

View raw message