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 Mon, 04 Apr 2005 12:00:54 GMT
Remy Maucherat wrote:
> On Apr 1, 2005 3:53 PM, Simon Kitching <> wrote:
>>Remy Maucherat wrote:
>>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.
> This does not make sense to me. It actually prevents classloading
> issues, and does not introduce problems as long as you can read the
> documentation.

The classloading issues arise when different logging-related classes are 
loaded via different classloaders.

If everything is loaded via the webapp classloader (WEB-INF/lib et al) 
then there is no problem. It is precisely Tomcat´s provision of *part* 
of the logging code via the shared classloader that causes the problem. 
When users put log4j (or whatever) in WEB-INF/lib but have jcl via the 
shared classloader that problems occur. Or they put commons-logging.jar 
in WEB-INF/lib but commons-logging-api.jar remains in the shared/lib dir.

Surely tomcat could have a container/lib directory in which jar files 
are visible to tomcat but not to the webapps? Putting jcl in here 
instead of shared/lib would then make logging in individual webapps much 
more predictable. Yes, webapps would then have to provide 
commons-logging.jar themselves in WEB-INF/lib, and that would cause 
duplicate copies in memory, but that also means that the individual 
webapps are properly isolated from each other. Optimisations with 
potentially complex side-effects (libs in a shared classloader) should 
be an *optional* step, not the default for the container.

>>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.
> Feel free to write your own logging API, then, with whatever gimmicks
> you need. It does not matter to me, as unlike c-l, java.util.logging,
> and log4j, I can safely ignore it ;)

Umm..what I am suggesting is that if people want such features they 
should select a logging library that offers them, then directly code to 
that libraries´API. All the features I describe are already present, or 
proposed, for various logging libraries.

Coding direct to a specific logging API is not acceptable when writing 
libraries. In that case you need to use a portable subset of the 
functionality via a wrapper like j.c.l or UGLI or similar.

Coding direct to a specific logging API is, however, a perfectly fine 
thing to do when the code is for an *application* which is deployed 
together with the author´s choice of logging library. Of course the 
author(s) may choose to use a wrapper anyway, for the reasons I listed 
in my previous email; tomcat has chosen to do that. I´m just trying to 
point out to Martin Cooper and others that JCL isn´t *trying* to solve 
every logging problem under the sun, and that a least-common-denominator 
API is fine for the most significant issue: logging developer-level 
information from inside library code.

>>>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.
> Unless you can provide hard numbers ...
> You apparently have never profiled Tomcat or any similar container

True. Real statistics are always the best tool. However I´m not going to 
spend a week acquiring them, so it´s informed speculation or no 
discussion at all :-).

I´m really basing my assertion on the fact that a call to a virtual 
method on an abstract class or interface must carry some overhead; I 
can´t see how the call could be inlined by either the compiler or the 
JVM (though a call to a final method could be).

However I can´t muster much enthusiasm to argue the performance case 
here; I agree it´s not likely to be measurable in most cases relative to 
other parts of the application.

> (suggesting it is a good idea, on any logging framework, to call
> getLogger inside your app's critical path is quite funny).

Really? When getLogger can return different Log objects depending upon 
the current context classloader? No class that could be deployed via a 
shared classloader should cache a Log object in a static field...

> there are not enough calls like that in the critical path to make it
> relevant in any way.

In earlier days, the log4j home page gave prime billing to statistics 
showing how fast log4j performed a log.debug("foo") operation when debug 
level was disabled. I see that has now disappeared; I can´t find that 
original page anywhere. I guess logging is now an accepted part of an 
application now, and people aren´t so paranoid about the performance.

But again I agree that such performance tuning is not relevant to most 
apps (though it can never hurt).

>>>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
> You mean library have a business deciding which logger people should use ?

I think you´ve misread my statement above. I´m saying that libraries 
must *not* make such assumptions. Applications *may*.



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

View raw message