axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Problems with commons-logging - Very interesting
Date Tue, 20 Dec 2005 20:16:27 GMT
On 12/20/05, Ceki Gülcü <> wrote:
> 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?

see below

> Considering that it took a very long time for JCL problems to be
> recognized,

that's not correct. the classloading issues and their fundemental
causes have been known for a very long time.

what was missing was the analytic approach to the problem which
allowed benefits to be correctly weighed and the acceptance that the
java classloading specifications are broken and that it's probably
better to be practical.

> how credible are the claims that the problems have been
> fixed?


please: let's not get personal

JCL is both technically challenging and very unrewarding. the only
reason i work on it at all is that i had a very small part in it's
creation and i feel some responsibility to the users. pushing JCL as
far as it's design will go is an important step along the road.

> Would you care to expand on the fixes, alternatively point us
> to a document describing them?

IIRC brian and simon went through most of them last year whilst you
were still lurking on list

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

some of these were fixed by brian and simon. others represent
limitations which are due to classloading specifications and others
which are innate limitations of dynamic binding. IMHO your document
would be more powerful if it were less focussed on advocacy and did
more to explain.

IIRC you saw a copy of the analytic document which extended your
examples in a more systematic fashion but if you are still interested
in the progress made in understanding the problem (and the limits that
any solution using dynamic binding can have) then let's take it
somewhere where it's on topic...

> Most importantly, if SLF4J were
> used instead, the problems discussed in Examples 2 through 7 would not
> have occurred.

it is easy to set up situations involving classloaders where
unintuitive things happen. i just don't think that there's any real
purpose served by me doing so for SLF4J. an advantage of static
binding is that it's very clear to the user when it's a classloading
issue: there's no magic involved.

> If this description is inaccurate in any way, please let
> me know where and how, and I will proceed to make the appropriate
> corrections.

we've been through this before. we disagree about some the fairness of
some of the conclusions you draw from your evidence given the likely
audience for the document. this is OT for this list and i don't have
the energy to waste arguing about what are subjective opinions

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

IIRC you commented on the analytic document which these fixes were
based on and seemed satisfied. simon and brian then took the document
and demonstration code and created a comprehensive set of unit tests
for the various classloading permutations.

we think that we've now caught all problems that (we believe) can be
fixed by using dynamic binding (as opposed to being consequences of
the classloading specification). all other classloader issues are a
consequence of the classloading specification and cannot be fixed by
solution which adopts the dynamic binding approach used by JCL.

IMO this is quite an achievement since it sets the known boundary for
this approach to the problem.

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

one of the problems that JCL has is that it is so widely used: the
vast majority of issues that users have with JCL could be fixed by
simply removing the duplicate jars. this is something that SLF4J
hasn't had to address yet. if users move to SLF4J and have multiple
SLF4J jars in the classloader hierarchy, they are still going to need
to do something similar.

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

any java component can have classloading issues :)

there are a different set of limitations which apply to all static
binding approaches. there are a few cases which IIRC seemed to be very
important in the days before the nightmares of J2EE classloading which
static binding at compilation time can't address.

but again this is OT so if you're interested we should take this somewhere else.

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

generally, if changing dependencies that will break backward
compatibility for a libary then it's almost always better to wait.

> Do you have an idea when JCL 1.1 will be
> released?

the code's been finished for many months

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

this available at SLF4J yet?

- robert

View raw message