geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: removal of spring dependencies from cxf module
Date Mon, 27 Aug 2007 18:16:49 GMT

On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote:

>
>
> Kevan Miller wrote:
>> K. Can you explain to me what functionality is being taken away? Dan
>> said function would be lost, but then listed functionality and  
>> said that
>> configuring them "becomes quite a bit harder". Nor do I know how this
>> increased complexity would be who bears the burden for things  
>> becoming
>> quite a bit harder.
>>
>
> Read Dan's comment/answer.  The functionality is the ease of
> configuration, etc.  For someone who has used Spring extensively, I
> think its a huge loss not to be able to leverage it.
>
>> I want the client application to be in control of the Spring  
>> version. I
>> don't want the Geronimo server environment to dictate the version of
>> Spring used by the client application. At present, we are  
>> dictating the
>> version of Spring. I think this needs to change. I don't think  
>> this is a
>> result of our ClassLoader structure.
>>
>
> What are you talking about...this is clearly a classloader  
> problem.  The
> fact the client and the server are fighting over whose version of  
> Spring
> is the "right one" points its finger at a classloader issue.  The fact
> the client has to set the hidden classes attribute on plans clearly
> shows this is a classloader problem.  Am I missing or not seeing
> something here?  If so, please point it out...perhaps I'm simply not
> getting it.  Clashing versions is about as classloader related as  
> it gets.
>
>
>>>
>>>>
>>>> I have no real issue with our CXF server module requiring Spring.
>>>>
>>>> I'm less happy if we're requiring that Spring be accessible from a
>>>> client application module to configure CXF web services client
>>>> capabilities.
>>>>
>>>> I'm way less happy if we require the same Spring instance be  
>>>> accessible
>>>> from the CXF server module and the client application module.  
>>>> This is
>>>> the case, at the moment. I think this needs to be changed.
>>>>
>>>
>>> Why should it be changed?  This seems to work with someone using
>>> Tomcat...just not Geronimo.
>>
>> Does Tomcat embed CXF? Does CXF distribute Tomcat binaries  
>> configured to
>> provide CXF-based web services? Or does CXF distribute CXF and
>> associated dependent jars which can be packaged into a WAR and
>> subsequently deployed into a web container?
>
> CXF can certainly be used in Tomcat.  Tomcat doesn't distribute it,  
> but
> it certainly can be used with that web container.  It appears the only
> project who has this problem is Geronimo :-/

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


Mime
View raw message