Hi Robert,
Thanks for your comments.
I would not go so far as to say I prefer SLF4J.
I was just raising the possibility that Axis 1.x might consider it. You are
absolutely correct in saying that if compatibility was adversely affected, then
waiting is the right thing to do.
I will also note that JRun (the
Macromedia/Adobe J2EE server) OEMs Axis and uses commons-logging to very
smoothly tie Axis logging to the JRun specific logging classes. Switching that
would probably break that system. L
So waiting for CL 1.1 is a reasonable
course of action.
--
Tom Jordahl
Adobe ColdFusion Team
From: robert burrell
donkin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 20, 2005
8:17 AM
To: [email protected]
Subject: Re: Problems with
commons-logging - Very interesting
On 12/19/05, Tom Jordahl
<[EMAIL PROTECTED]> wrote:
One of my developers found this very interesting paper on the problems
using commons-logging (like Axis 1.x does) while trying to upgrade
ColdFusion's log4j implementation from 1.1 to 1.2.
http://www.qos.ch/logging/classloader.jsp
a few points i'd like to make:
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.
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.
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.
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.
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).
If Tom prefers SLF4J then a JCL-SLF4J static bridge may be the answer.
- robert
|
