geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: removal of spring dependencies from cxf module
Date Mon, 27 Aug 2007 21:29:39 GMT
No...that made much more sense to me ;-)

I think convenience is the way to go.  I am following you now.



David Jencks wrote:
> 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 :-)
> thanks
> 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, IMNSHO,
>>>> 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