commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Sat, 02 Apr 2005 10:47:10 GMT
On Fri, 2005-04-01 at 16:38 +0200, Remy Maucherat wrote:
> 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.

classloaders are tricky and good practical documentation on them sparse.
improving the JCL documentation in the direction of practical
troubleshooting is a priority for me.

there is one case which has turned up in my analysis where an impl only
distribution is needed. the use case is not uncommon amongst web
application developers. until this is addressed, the last statement
probably needs qualification. 

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

hot spot virtual machines do weird (and sometimes wonderful things). for
example, the isDebugEnabled call is made frequently so there is a chance
that it may be optimized away. profiling really is crucial.

- robert


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