geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: removal of spring dependencies from cxf module
Date Mon, 27 Aug 2007 21:23:34 GMT

On Aug 27, 2007, at 11:26 AM, Jeff Genender wrote:

> David,
> So perhaps I am missing something and you could help clarify this.   
> You
> say "It's by no means obvious to me that treating this as a problem  
> with
> the coding of our classloaders is appropriate."  Yet in your 1, 2,  
> and 3
> options, you seem to be saying its basically a problem with
> classloading.  Is it our classloaders, or is it Spring's (or other)?

Sorry I'm not being clear.
1>> problem with cxf that no amount of changing our classloader code  
or configuration will fix.  The same problem would occur in tomcat if  
you tried to use a spring version incompatible with cxf.

2>> our classloader works as long as you provide spring in the web  
app for use by the web app.  We could optionally enhance our  
classloader so a user would not need spring added to hidden-classes  
for the web app.

3>> For ease in making sure the classes from our copy of spring are  
normally loaded in the same classloader no matter who is using them,  
we might consider have a spring configuration with just the spring  
classes in it.  This would be more useful if the optional enhancement  
suggested in (2) was made.

So I don't see any way the code in our classloaders is wrong.  We  
might be able to make some things more convenient, and one of those  
things would involve a new feature in our classloaders.

I know there's a good chance I'm still writing incomprehensibly, so  
don't be shy if this still doesn't make sense :-)

david jencks

> Jeff
> David Jencks wrote:
>> Cool down a minute and think about this.  What happens in tomcat  
>> if you
>> want to use cxf + an incompatible version of spring in your app?  You
>> bundle cxf + springA + springB into your web-app and then what  
>> happens?
>> IMO we are talking about trying to get geronimo to generically  
>> solve a
>> problem that tomcat forces its users to deal with on an per-app  
>> basis.
>> It's by no means obvious to me that treating this as a problem  
>> with the
>> coding of our classloaders is appropriate.  Here  are some  
>> possibilities
>> I can think of off the top of my head:
>> 1. cxf generates some code  for each web service client/service that
>> directly use spring classes.  In this case there is AFAIK no way  
>> for an
>> app to use a different spring version since these generated  
>> classes are
>> going to be loaded in the application classloader and they need  
>> access
>> to cxf's copy of spring classes.  If this is what is going on I hope
>> it's possible for cxf to stop doing this.
>> 2. If putting spring in the apps hidden-classes works and allows  
>> the app
>> to use a different spring version, then evidently (1) isn't a  
>> problem.
>> In this case if we automatically add spring to hidden-classes of  
>> every
>> app we would be preventing all apps from using our copy of spring  
>> which
>> seems undesirable to me.  hidden-classes currently means "don't  
>> import
>> these classes from parents".  We could look into also having a "don't
>> export these classes to children" filter in our classloader.
>> 3. With just the "don't export" filter proposed in (2), people adding
>> the spring jars to their dependency list would be getting spring  
>> loaded
>> in a different classloader for their app and for cxf.  This might  
>> not be
>> desirable.  We could make a spring configuration to provide a single
>> classloader to load spring in that cxf and apps could depend on.
>> thanks
>> david jencks
>>>> I believe it's the latter. In which case, you're not giving me an
>>>> apples-to-apples comparison, IMO.
>>> Well...lets agree to disagree.  The bottom line is we are castrating
>>> other projects because we have messed up classloaders.  That,  
>>> has nothing to do with apples-to-apples comparison and we are  
>>> creating a
>>> treatment to the problem rather than a panacea.
>>> Do as you may, but call my issue with how we are handling this a
>>> dissenting voice.  I am not in agreement with this action.
>>>> --kevan

View raw message