On Jul 31, 2007, at 10:47 AM, Jarek Gawor wrote:
I'm +1 on the testing this out. I seem to remember that a while ago
I've had some problems with CXF when the <hidden-classes/> was
actually enabled for Spring classes in the Jetty config but maybe it
will work better now. See:
http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html.
Please also run the
testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify
that everything works ok after the change.
But I have a few comments on this change in general. First, why are we
adding the <hidden-classes/> bits for Spring and CXF only? Aren't we
in the same boat with other libraries, e.g. Axis2, Commons Logging,
etc.? Also, I think the <hidden-classes/> change should go into both
Tomcat and Jetty configs (since for example the Tomcat assembly could
be switched to run CXF).
Yes, there is always an exposure for problems with parent libraries.
As you might expect, what libraries are exposed to client
applications has been discussed, before... You could make a case that
we should offer a simple configuration mode where we offer only
strict EE interfaces to client applications, default would remain our
current behavior. I don't see this happening for 2.0.
As to why treat Spring differently:
1. Spring is especially prone to version incompatibilities. We only
include spring core, context, and beans jars in the cxf module. Since
most apps will have additional Spring jar files, we are exposed to
problems caused by method signature incompatibilities.
2. Spring problems are what have shown up on our user list/jiras.
Yes. I had the same filters in the tomcat deployer...
--kevan
