axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: Problems with commons-logging - Very interesting
Date Tue, 20 Dec 2005 15:24:43 GMT


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


    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

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

  > If Tom prefers SLF4J then a JCL-SLF4J static bridge may be the answer.

Yes, indeed.

Ceki Gülcü

   The complete log4j manual:

View raw message