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 Tue, 02 Aug 2005 21:48:25 GMT
On Tue, 2005-08-02 at 20:00 +1200, Simon Kitching wrote:
> [AARGH - I hate top-posting!]
> I'm not opposed to this proposal. Commons-logging already creates a
> proxy Log object for each underlying real logger object, so at the worst
> the name can be remembered at the Log object level as far as I can see.
> In other words, this functionality should be possible to implement
> whatever the underlying logging library. 
> And I'm generally convinced by the emails to this thread that all
> reasonable logging libraries provide a way for logging objects to return
> their name anyway.
> I don't personally have any need for this feature, but it seems that
> people with reasonable credentials do.
> So overall I'm in favour of some kind of implementation of this feature.
> Commons-logging needs to be *very* careful about adding features to its
> API but this seems to me like one that passes the necessary tests.
> If you were to create a bugzilla entry with an implementation of this
> feature and supporting unit tests [and assuming no-one else votes
> against it] I will review and commit it sometime in the next few weeks.

i see no reason (so far) to veto :) 

i've been thinking for a few months now that the long term solution to
the difficulties associated with bridging APIs might be a logging
specification (*not* an implementation which is IMHO where we've been
going wrong). 

this would take ceki's static binding to another level: the
specification should describe only a logging API with all the discovery
and so on left entirely to the implementation. retrofitting this to JCL
would allow slf4j to replace JCL (and the opposite) by just replacing
the jars in the classpath. it would also provide a very clean way for
JCL to provide specific implementations for specific purposes. 

given the backing of the JCL committers and the slf4j subscribers, i
really think that this approach would stand a good chance of creating
sufficient momentum to unify the various bridges out there. i've been
thinking of posting a proposal to slf4j (but had been considering
waiting until the slf4j interface was more mature).

opinions welcomed

i'd also be very interested to hear what the experts on the slf4j make
of these ideas. Jörg and/or joerg: want to volunteer to raise it?

> Note, however, that commons-logging isn't making much progress at the
> moment, and several issues standing in the way of a new release. So
> there's no guarantee of when the next release might actually be pushed
> out.

i hope to have a bit more time now but i've now lost track of where we

- robert

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

View raw message