geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: removal of spring dependencies from cxf module
Date Mon, 27 Aug 2007 20:01:55 GMT

On Aug 27, 2007, at 2:16 PM, David Jencks wrote:

>
> On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote:
>
>>
>>
>> Kevan Miller wrote:
>>>
<snip>
>
> 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.

Mostly correct, I think. IIRC, this worked except for one measly WS- 
Policy test case in testsuite. This test failed with Spring hidden- 
classes. I then attempted to get a unique instance of Spring running  
in the application classloader and the test still failed. It would  
only work if Spring was loaded from the parent ClassLoader. Given  
what I've learned from Dan, I'm starting to think that this was  
likely a configuration problem. If we were not able to read a server- 
wide CXF configuration (because it was hidden), then the client  
application might not have had the expected configuration -- thus the  
test failure. This is pure speculation, at the moment...

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

Hmm. Maybe. Definitely worth investigating.

--kevan



Mime
View raw message