Hello,
> 1 IIRC all the factual errors in earlier versions have been correctly > but IMO there are a (small) number of opinions which may be misleading > to those without a deep understanding of classloaders. Have the vulnerabilities in JCL really been fixed this time? Considering that it took a very long time for JCL problems to be recognized, how credible are the claims that the problems have been fixed? Would you care to expand on the fixes, alternatively point us to a document describing them? > 2 though Ceki made some important points and his article definitely > contributed to a more analytic approach to the known issues with JCL, > some points are a little unfair since it is possible to set up similar > scenarios for the compilation-time static-binding approach used by > SLF4J. Robert, thank you for acknowledging my contribution. I appreciate that. It is true that "Example 1" describes general class loader issues independent of JCL. Please note that this is clearly labeled in Example-1. Here is the quote from my "Taxonomy of class loader problems" document: Example-1 This first example, ParentFirstTestJCL0, will not explicitly set the TCCL. Thus, the TCCL will default to the system class loader. Please note that this example does not illustrate a bug in JCL but rather serves as a warm up for the rest of the examples. Although Example-1 does not describe a JCL bug, Examples 2 through Example 7 *do* describe JCL bugs. Unless I am missing something, the examples denote JCL specific problems. Most importantly, if SLF4J were used instead, the problems discussed in Examples 2 through 7 would not have occurred. If this description is inaccurate in any way, please let me know where and how, and I will proceed to make the appropriate corrections. > 3 all the problems which can be fixed (within the limitations that the > various specifications impose on any logging bridge that uses dynamic > binding) are believed to be fixed in the upcoming 1.1 release. Is there a place were these fixes are described? > >> We might want to consider converting Axis 1.x to use the SLF4J: >> http://www.slf4j.org/ >> >> We encountered several of the problems mentioned in the paper >> specifically because Axis uses commons-logging instead of log4j >> directly. >> > > be aware that there is a degree of trade off here. the problems which > JCL has with classloaders are a direct result of the mess made of the > various Java specifications related to classloaders. SLF4J isn't as > widely used as JCL and is still under development. the original JCL > code was created by a team contained developers who were (at the time) > as knowledgable as any about the relevant specifications and about > classloading but the code even they produced didn't stand the test of > time. ceki's team are also good but their approach (though promising) > hasn't been analysed in great detail and it's possible that early > adopters may suffer. There is no denying that JCL is more widely used than SLF4J. However, SLF4J will never cause class loader problems because it just relies on the JVM to load classes, Unlike JCL, SLF4J does not hold references to class loader instances. > IMHO if shifting to SLF4J would break backwards compatibility (in > axis) then I'd recommend waiting for a little while (for SLF4J to be > released and for JCL 1.1). The SLF4J latest version is currently 1.0RC3. Its API will not change between now and 1.0 final. Do you have an idea when JCL 1.1 will be released? > If Tom prefers SLF4J then a JCL-SLF4J static bridge may be the answer. Yes, indeed. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/
