Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 94694 invoked from network); 11 Aug 2004 08:59:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 11 Aug 2004 08:59:48 -0000 Received: (qmail 88498 invoked by uid 500); 11 Aug 2004 08:59:37 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 88273 invoked by uid 500); 11 Aug 2004 08:59:35 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 88257 invoked by uid 99); 11 Aug 2004 08:59:34 -0000 X-ASF-Spam-Status: No, hits=1.6 required=10.0 tests=RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL X-Spam-Check-By: apache.org Received: from [80.238.41.184] (HELO mail.qos.ch) (80.238.41.184) by apache.org (qpsmtpd/0.27.1) with ESMTP; Wed, 11 Aug 2004 01:59:31 -0700 Received: from kal.qos.ch (kal [192.168.1.3]) by mail.qos.ch (Postfix) with ESMTP id B9C011EC073 for ; Wed, 11 Aug 2004 11:18:21 +0200 (CEST) Message-Id: <6.0.3.0.0.20040811101747.034a6150@mail.qos.ch> X-Sender: ceki@mail.qos.ch (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 11 Aug 2004 10:59:51 +0200 To: tomcat-dev@jakarta.apache.org From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: old issue of log4j trying to use the previous classloader Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hello, At 2004-01-23 11:54, just 4 minutes after bug number 26372 [1] was filed, Remy Maucherat threw it out, saying: This is the old issue of log4j trying to use the previous classloader (reloading will create a new classloader to load class definitions; see bug 3888 [2]). Maybe it would be good to leave this bug open so that people can complain using it, rather than file duplicates. However, I'd like everyone to know that the "bug" will never be fixed. You can probably fix the problem by putting log4 JARs (and the necessary commons-logging wrapper classes) inside the webapp repository. What old issue of log4j trying to use the previous classloader is Remy referring to? I am not aware of any log4j code that holds on to classloader references. If Remy was misinformed, he should retract his previous statements about log4j holding classloader references. On the other hand, if his claims are substantiated, I would be happy to study the evidence and work to correct any mistakes. Latest evidence [3] indicates that the java.lang.ThreadDeath problem has it's root causes in classloader references held by commons-logging. As the commons-logging dynamic discovery mechanism is based entirely on tracking various classloaders, there is no doubt that commons-logging holds on classloader references. For the sake of our users, I would appreciate if tomcat-developers could shed more light onto the matter. [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=3D26372 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=3D3888 [3] http://issues.apache.org/bugzilla/show_bug.cgi?id=3D27371 --=20 Ceki G=FClc=FC --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org