geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Date Mon, 17 Sep 2007 16:23:29 GMT
On Sep 14, 2007, at 7:58 PM, Kevan Miller wrote:

> Heh. Well, I had hopes for Paul's proposal... Sounds like it's  
> still better than where we are now...

I was also thinking that it's a step forward, but now it's not clear  
to me whether moving the spring filter to cxf-deployer would break  
cxf's spring-related stuff, or just leave us with some non-critical  
issues to resolve.  If it's the latter case then can we commit as an  
interim step so the admin console can start working again?

> I think the right way to address the problem is at the CXF module,  
> itself (which we've talked about on other threads). Basic idea is  
> that the CXF module would declare the classes that it will hide  
> from classloader children.
> You'd specify something like:
>                 <child-hidden-classes>
>                     <filter>org.springframework.</filter>
>                     <filter>META-INF/spring</filter>
>                 </child-hidden-classes>
> The CXF module classloader would hide these classes/resources from  
> child classloaders. We could also consider separating <hidden- 
> classes> and <hidden-resources>...

I think that the more we can attach the filters to the actual  
components that need them the better, so I really like your idea.   
Another variation would be to extend the <inverse-classloading>  
element that Geronimo currently supports to include filters that  
affect whether child components get the parents' or their own  
versions of certain classes.   i.e. something like:


would tell Geronimo to prefer loading the spring classes from the  
child's classloader.

> Other final (?) thing to consider is creating a Spring module. Both  
> cxf and pluto-support could depend on this new module...

I thought about this too but couldn't think of a way for apps to  
share the Spring classes in a classloader without potentially  
stomping on each other's spring configuration and bean factories.

Best wishes,

View raw message