geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [jira] Commented: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
Date Sat, 01 Oct 2005 15:50:01 GMT

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.

david jencks

View raw message