On Apr 1, 2005 3:53 PM, Simon Kitching <[EMAIL PROTECTED]> 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
