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