tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: Why commons-logging-api.jar?
Date Thu, 24 Apr 2003 19:42:30 GMT
At 08:29 PM 4/24/2003 +0200, Remy Maucherat wrote:

>The non delegating CL in Tomcat 4 is nothing but a source of problems, 
>which cannot be implemented to actually work. You need to have an endless 
>supply of particular workarounds for various libraries to avoid class 
>I think in the case of log4j + c-l, there are issues if you attempt to 
>override. Personally, I like JDK 1.4 logger better, because it's hassle 
>free, and I have yet to see it cause applications to fail. I still have a 
>really annoying bug report open, which seems to be caused by log4j, and 
>which would also indicate that log4j creates CL problems: bug 3888. You 
>seem to insist that it's Tomcat's fault, though.

The bug report is available here:

As you can see and read, all I have done is correct the log4j bug reported by
Jacob Kjome possibly related to 3888. As far as I can tell, that log4j
bug as reported by Jacob has been solved in log4j 1.2.8.

Jacob Kjome has gone to great lengths to make the bug reproducible. He
also stated on 2002-11-01 01:53 that bug #3888 was not caused by log4j.

He also wrote on 2003-02-24 04:14

   I actually am not getting the "INFO: Lifecycle error : CL stopped"
   error unless I do Log4j configuration.  However, I've somewhat ruled
   out Log4j as the culprit because, although I don't get said error
   printed out when I don't explicitly configure Log4j, I get the same
   behavior of the context not starting after the 4th step in either
   case.  Doing the configure must just trigger the code that actually
   prints out that debugging where that same debugging code isn't
   triggered otherwise.

Note that line 644 in DOMConfigurator where the error seems to occur
just creates a new XML DocumentBuilderFactory:

line 644:   dbf = DocumentBuilderFactory.newInstance();

If people reporting the bug state that it is not log4j related, then
that is good enough for me. Nevertheless, if you or anyone else has a
specific log4j bug to report, I'd be glad to fix it (if I can).

>So since the current situation works (I didn't hear about CL problems with 
>4.1.24 related to logging), I'm clearly in favor of keeping the status 
>quo, and will veto any related proposals for 4.1.x.

How about 17323? It was a nightmare to identify. You might also want
to read on my personal
experience with this bug.

If the logging component is not 100% reliable, then important stack
traces can get lost making it unnecessarily difficult to identify
bugs. Good and clear stack traces are one of the great advantages of
Java over languages like C.


Ceki  For log4j documentation consider "The complete log4j manual" 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message