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?
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. Jarek On 9/17/07, Paul McMahan <[EMAIL PROTECTED]> 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 >
