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 17:42:05 GMT
On Sep 17, 2007, at 12:48 PM, Jarek Gawor wrote:

> Paul,
> In the new admin console, do the web applications (that provide
> portlets) need to share Spring version/configuration with the Pluto
> config module? What if each web application had its own Spring jars?
> Would that work?

Actually the portlet webapps don't need to share Spring, they need to  
share Pluto.   Pluto needs to be in a parent configuration for those  
webapps so that they can know about each other's portlets via the  
classloader.   The tricky part here is that Pluto uses Spring  
internally for configuration and needs for it to be in the same  
classloader as the Pluto jars.   So this is not a clear cut case of  
apps needing to share Spring but rather apps needing to share  
something that depends on Spring.   In fact this might be a more  
common scenario than sharing Spring itself since nowadays many  
components use Spring for configuration.

> Moving the Spring filters to cxf-deployer is better from the
> modularity point of view (and I'm all for it) but the end results will
> be the same in this case. I think Kevan's idea might be the best
> solution here.

The end results here being that Spring-based webapps that contain web  
services would inherit cxf's copy of Spring?   Or that cxf could not  
use Spring to configure itself?  Or something else?  I'm still not  
clear on what breaks or becomes more difficult if we move the filter  
to cxf-deployer or remove it altogether.

I'm wondering if we can target our solution only at assemblies that  
contain cxf since the current solution affects the minimal and axis  
based assemblies where it may not be needed.  I guess that's in line  
with your comment about modularity, and I agree with you and Kevan  
that a new classloader knob for deployment plans is probably the best  
way to accomplish this.

Best wishes,

View raw message