geronimo-dev mailing list archives

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

David Jencks wrote:

> With our current classloaders I think we need to include commons logging 
> in the exclusion list for the reasons Aaron explains. 

Agreed - there never was any argument here.  Already done..GERONIMO-518 
patches have been applied and committed to HEAD and M5.

> 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. 

+1. ;-)  I look forward to working on this stuff.

> 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.

I don't agree with you about not removing the hard coded part.  What if 
I write my own patches to commons-logging to fix some of these issues 
and do my own specialized logging.  I then need the o.a.c.l package 
structure, as a user.  By hardcoding this, you have taken that ability 
for me to do jars will never get used. I am against 
this...this takes away complete control from the user to patch and make 
their own o.a.c.l versions.  What happens then?  Do we tell the user 
"too bad"...or should we give them a choice of excluding it via a 
configuration, so they can roll their own o.a.c.l library?


1) Hard code now (M5)
2) Remove hard code and create an exclusions list (1.0)
3) Remove exclusions list and fix the classloaders (Post 1.0)

For number 2, we could easily create a warning if the user has 
commons-logging in the web-inf/lib and its not excluded.  But lets give 
the user a choice.  This takes us out of the loop completely from a 
support perspective.

> thanks
> david jencks

View raw message