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 18:26:41 GMT

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)?


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