Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jgenender@savoirtech.com
 designates 209.181.65.237 as permitted sender)
Message-ID: <433EB526.5000805@savoirtech.com>
Date: Sat, 01 Oct 2005 10:11:18 -0600
From: Jeff Genender <jgenender@savoirtech.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: [jira] Commented: (GERONIMO-518) Deploying Struts app fails on
 Logging ClassCastException
References: <640914344.1102300702638.JavaMail.apache@nagoya>
	 <1632517066.1128016727763.JavaMail.jira@ajax.apache.org>
	 <46494.12.17.202.43.1128020660.squirrel@mirage.savoirtech.com>
 <74e15baa0510010734s7c8898ccx837f872002ebe555@mail.gmail.com>
In-Reply-To: <74e15baa0510010734s7c8898ccx837f872002ebe555@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Aaron Mulder wrote:
> On 9/29/05, Jeff Genender <jgenender@savoirtech.com> wrote:
> 
>>But I want to emphasize my discomfort with harcoding a commons package
>>into these loaders as it ultimately takes waya control from the user.  As
>>long as we can back this out and do a proper exclusion list in a
>>configurable plan, then I am cool with it.
> 
> 
> Could you explain what you mean here?  I think we've already seen that
> in the case of commons logging, if you give that control to the user
> (by exposing a list including commons logging) and they exercise it
> (by removing commons logging from the list and including their own
> commons logging JAR), they get a ClassCastException -- which is to
> say, it doesn't work include your own commons logging and try to use
> it instead of Geronimo's version.  

To answer your question, it goes back to my original statement.  I think 
we should not be patching with hardcoding for other APIs.  Why?  Because 
we will undoubtably run into this with other packages in time.  The next 
commons-[insert your package here] that implements a similar technique, 
then are we to do another hardcode?  Once we start hardcoding others' 
APIs, then we start to become responsible for the fixes if they don't 
work right.  The mere fact that the author of this package advocated 
removal from the web-inf/lib directory, in and of itself, is a clear 
warning that we are patching of others' issues.  Minimally we should 
allow the user to make the final decision of whether he/she wants 
delegation to the server classes or not.  IMHO...I would rather give 
more control to the user and let them decide to exclude it.  I don't 
think that decision should be forced by us.  But this is a semi-short 
term solution...read the answer to your next question below.


> I think the only way to work around
> that is a much more detailed restructuring of our ClassLoader
> hierarchy.  Do you have another proposal for "making commons logging
> overridable"?

I agree and I think David Jencks' email on this (as well as yours and my 
email discussions) may be the ultimate solution.  The problem is 
essentially due to our classloader being too permissive about access.  I 
think you pointed this out earlier, and you and I had consensus on this. 
  The really short term solution is to hard code the commons-logging 
package. The semi-short term solution is a plan based exclusion list. 
The long term is to fix the class loaders.  Do we agree on this?

Jeff

> 

> Thanks,
>     Aaron