geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
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:48:57 GMT

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?

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.


On 9/17/07, Paul McMahan <> wrote:
> 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:
> <inverse-classloading>
>      <filter>org.springframework.</filter>
> </inverse-classloading>
> 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,
> Paul

View raw message