On Sep 11, 2007, at 5:37 PM, Jarek Gawor wrote:
I think we have an acceptable solution for this whole CXF/Spring
issue. First, CXF will continue to be configured with Spring as
before. Second, all web applications will now get an automatic
<hidden-classes> filtering for Spring classes and resources. That
should enable applications to have their own versions of Spring and
reduce conflicts with Geronimo's version.
The key to this solution was ensuring that CXF was
initialized/configured with the CXF module classloader and not the
application classloader. If the application classloader was used, and
it had Spring filtering enabled, the Spring configuration files were
filtered away. That caused incomplete configuration of CXF and
failures later on.
When CXF module classloader is used, the right Spring configuration
files are discovered and things work nicely. Of course, now if the
application has its own CXF configuration files they will be ignored.
So this solution is not perfect but hopefully should be good enough
for 2.0.2.
I committed the changes to trunk and branches/2.0 if people want to
review.
Cool. Thanks Jarek!
I think this will fix the Spring problems, we've seen to date with
Jetty/CXF. There are still some things we can do, in addition to this:
1) Create a separate Spring module. The CXF module would be dependent
upon this module. Other system modules could also be dependent upon
this Spring module. Optionally, client applications could have a
dependency on this module.
2) Currently, our ClassLoaders can only filter classes from their
parents. Would be cleaner if we allowed the CXF module to filter
Spring classes from its children.
3) Would be good to upgrade our Spring version. There used to be a
problem with 2.0.5+ versions of Spring and XBean. I think I've fixed
that in XBean. Possible that CXF has an issue with newer versions of
Spring.
--kevan
