commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <remy.mauche...@gmail.com>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Fri, 01 Apr 2005 14:38:05 GMT
On Apr 1, 2005 3:53 PM, Simon Kitching <skitching@apache.org> wrote:
> Remy Maucherat wrote:
> I´d assumed that the information about JULI here:
>    http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html
> 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.

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.

> 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 ;)

> > 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
(suggesting it is a good idea, on any logging framework, to call
getLogger inside your app's critical path is quite funny). As I said,
there are not enough calls like that in the critical path to make it
relevant in any way.

> > 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
> choose.

You mean library have a business deciding which logger people should use ?

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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message