geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: [jira] Commented: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
Date Sat, 01 Oct 2005 16:55:42 GMT

On Oct 1, 2005, at 11:50 AM, David Jencks wrote:

> On Oct 1, 2005, at 7:34 AM, Aaron Mulder wrote:
>> On 9/29/05, Jeff Genender <> 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.  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"?
> With our current classloaders I think we need to include commons  
> logging in the exclusion list for the reasons Aaron explains.   
> There may be a possibility of actually solving the problem with  
> more sophisticated classloaders that actually hide all the server  
> classes from the applications.  From some conversations with Dain I  
> think the OSGI classloaders are capable of doing this, and I think  
> he is looking into the possibility of using them or something like  
> them.  I suspect this would be a post 1.0 change however.  For 1.0  
> I think the best we can hope for is a configurable exclusion list,  
> and my understanding is that you should not be able to remove  
> commons logging from the "fixed" part of the exclusion list.

If there's ever a reason why a user would want to remove it from the  
"fixed" part of the exclusion list, maybe allow  a minus sign or  
something in front of the class name in the exclusion configuration,  
like "-org.apache.Clogging" which says "Don't exclusde - I know what  
I'm doing so let me do this"

Is that a resonable compromise?


Geir Magnusson Jr                                  +1-203-665-6437

View raw message