Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <46D34243.60500@apache.org>
Date: Mon, 27 Aug 2007 15:29:39 -0600
From: Jeff Genender <jgenender@apache.org>
Reply-To: jgenender@apache.org
Organization: Apache Geronimo
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: removal of spring dependencies from cxf module
References: <A8E5C383-A0B0-42E3-ACA6-AD636D8BAFFB@gmail.com>
 <200708251744.53082.dkulp@apache.org>
 <8823AF1A-659B-47EC-94DA-CDFCA8DF67BF@gmail.com>
 <46D2DB91.6050900@apache.org>
 <73DE2547-FC9B-42AC-A442-D5E9235F6963@gmail.com> <46D2F69B.807@apache.org>
 <373692F9-823E-4ADF-8FF3-A066DDC5BAC4@yahoo.com>
 <46D31761.2030407@apache.org>
 <6A872A49-B07D-4FC3-95A2-A90361796FF6@yahoo.com>
In-Reply-To: <6A872A49-B07D-4FC3-95A2-A90361796FF6@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

No...that made much more sense to me ;-)

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

Thanks,

Jeff

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