commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Fri, 01 Apr 2005 13:53:10 GMT
Remy Maucherat wrote:
> On Sun, 27 Mar 2005 20:21:04 +0200, Simon Kitching <> wrote:
>>There really is no reason for an application to use JCL. I´m personally
>>surprised that Tomcat chose to do so for its internal logging, and
>>pleased to see that the next version is moving away from it.
> That's news to me.

I´d assumed that the information about JULI here:
meant that use of JCL was obsolete. Sorry if I misunderstood.

If tomcat had really chosen to move away from JCL (or at least removed 
commons-logging-api.jar from the shared classpath) that would certainly 
have made life easier for the commons-logging maintainers, as the 
presence of jcl in the shared classpath is the root cause of the main 
problems experienced by jcl users.

>>JCL is great for libraries, where the code *cannot* make any assumptions
>>about what logging library is available. However there is a significant
>>price to pay for using JCL:
>>  * a "least common denominator API", and
> We have never needed anything more.

Hmm..Martin Cooper´s email in this same thread has this:
This is a puzzling comment to me. What is the basis of the statement
that "nearly everyone" uses Commons Logging? No project that I have
ever worked on (outside the ASF) has ever used Commons Logging. They
have all used Log4j because of its feature set. I really don't think
I'm a part of a small minority here either.

I do quite like the idea of an API that has:
   log.debug("an {0} happened", "event");

JCL doesn´t provide any generic method of form
   log.log(LOG.DEBUG, "a message");

It doesn´t provide custom logging levels. And it doesn´t provide a way 
of querying what the current log level is, other than

I agree that none of these are critical, and code can be written 
satisfactorily without any of these features; tomcat is living proof of 
that. But the fact remains that these features are not in JCL because 
JCL is a "least common denominator" API; *some* logging implementations 
don´t provide these, so JCL can´t.

>>  * a significant performance hit.
> JFluid didn't ever show logging as an issue, so it does not matter to me.

It does depend upon usage patterns. My particular concern is that 
"isDebugEnabled" is a very carefully optimised operation in log4j. 
Calling it via JCL at least doubles the time taken. And similarly for 
getLog("foo"). Agreed, that does only matter if such calls are inside 
very tight loops which is probably not good practice anyway.

>>Application code which can make assumptions about what logging library
>>it will be bundled with should generally code directly to that logging
>>libraries´API. The app then gets a more complete API and better
>>performance. [1]
>>And libraries which provide fairly simple functionality don´t need
>>logging at all; they can report problems via exceptions.
>>But for libraries that are complex enough to need logging, but can´t
>>assume a particular logging implementation, what options are there other
>>than commons logging (or UGLI once it is released)? I would really be
>>interested to know! Hard-wiring the use of log4j into such a library
>>isn´t an option for obvious reasons.
>>Please note that the above is just my personal view..
> I don't think Tomcat has a buisiness deciding which logger people
> should use, just the same as for your libraries.

Well, libraries *cannot* make such assumptions. Application writers can 
decide which side of the JCL vs concrete-logging tradeoff they want to 



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

View raw message