Return-Path: 
 <dev-return-17704-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 94779 invoked from network); 30 Sep 2005 04:58:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 30 Sep 2005 04:58:32 -0000
Received: (qmail 12335 invoked by uid 500); 30 Sep 2005 04:58:21 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 12278 invoked by uid 500); 30 Sep 2005 04:58:20 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Received: (qmail 12267 invoked by uid 99); 30 Sep 2005 04:58:20 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Sep 2005 21:58:20 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of jgenender@savoirtech.com
 designates 209.181.65.237 as permitted sender)
Received: from [209.181.65.237] (HELO sun.savoirtech.com) (209.181.65.237)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 29 Sep 2005 21:58:24 -0700
Received: from [206.197.197.26] ([206.197.197.26])
	by sun.savoirtech.com (8.13.4/8.13.4) with ESMTP id j8U4unZr023446
	for <dev@geronimo.apache.org>; Thu, 29 Sep 2005 22:56:49 -0600
Message-ID: <433CC5D2.1020701@savoirtech.com>
Date: Thu, 29 Sep 2005 22:57:54 -0600
From: Jeff Genender <jgenender@savoirtech.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: [jira] Updated: (GERONIMO-518) Deploying Struts app fails on
 Logging ClassCastException
References: <640914344.1102300702638.JavaMail.apache@nagoya>
	 <1762927199.1127835052895.JavaMail.jira@ajax.apache.org>
	 <50137.12.17.202.43.1127836413.squirrel@mirage.savoirtech.com>
	 <b8b1243f0509270945762d813a@mail.gmail.com>
 <7b3355cb050929124341d88c7c@mail.gmail.com>
In-Reply-To: <7b3355cb050929124341d88c7c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on sun.savoirtech.com
X-Virus-Scanned: ClamAV 0.87/1105/Thu Sep 29 15:31:04 2005 on
 sun.savoirtech.com
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org
X-Old-Spam-Status: No,
 score=-105.3 required=5.6 tests=ALL_TRUSTED,AWL,BAYES_00,
	USER_IN_WHITELIST autolearn=failed version=3.0.4
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Bruce has shown us a great article that clearly explains the issues and 
solutions:

http://www.qos.ch/logging/classloader.jsp

It describes this problem in detail...and it says (near the bottom) for 
a solution:


"For Tomcat 5.0.27 and later,
<snip>
    4. Do not include any other copies of commons-logging.jar and 
log4j.jar in your web-applications' WEB-INF/lib/ directory.
<snip>
"


So...do we really want to hack up the classloader?  Please read the 
article..its fascinating.  Thanks for the link, Bruce.

Jeff



Bruce Snyder wrote:
> On 9/27/05, Kevan Miller <kevan.miller@gmail.com> wrote:
> 
>>Good point. I didn't notice that they were including Commons in their
>>WEB-INF/lib. I think this is related to the context-priority-classloader
>>discussion I brought up last week.
>>
>> Section 9.7.2 of the Servlet spec specifies that for a J2EE product "The
>>container should not allow applications to override or access the
>>container's implementation classes". Depending on your definition of
>>"implementation classes", Geronimo's servlet classloaders permit a number of
>>"implementation classes" (including commons-logging) to be loaded from the
>>web app's context. As this situation points out, this can lead to a number
>>of problems.
> 
> 
> The same section of the same spec also states the following:
> 
> 'It is recommended also that the application class loader be
> implemented so that classes and resources packaged within the WAR are
> loaded in preference to classes and resources residing in
> container-wide library JARs.'
> 
> Tomcat is a good exmaple of this in that it provides each webapp its
> own class loader. And therein lies the reason I have always
> recommended that each webapp should handle it's own logging (i.e.,
> contain it's own logging jars and configuration files) *completely
> separate* from the app server. I've seen far too many webapps that
> utilize the app server's logging mechanism for an individual webapp.
> IMO, this is simply wrong becuase it's using what I consider to be a
> side effect as a feature.
> 
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
> 
> The Castor Project
> http://www.castor.org/
> 
> Apache Geronimo
> http://geronimo.apache.org/