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
