commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Mon, 04 Apr 2005 14:33:22 GMT
On Apr 4, 2005 4:00 AM, Simon Kitching <skitching@apache.org> wrote:
> Remy Maucherat wrote:
> > On Apr 1, 2005 3:53 PM, Simon Kitching <skitching@apache.org> 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.

I think you have me confused with someone else. I'm well aware of this, thanks.

--
Martin Cooper


> >
> >
> >>>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
> >>choose.
> >
> >
> > 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*.
> 
> Regards,
> 
> Simon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

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