Known issue with provided SOAP Web Services

Wanted to highlight a known issue with the SOAP Web Services that causes some SOAP client libraries to fail since a referenced XSD file cannot be retrieved. The following file configures Axis to provide SOAP Web Services:

/path/to/percussion/AppServer/server/rx/deploy/rxapp.ear/rxapp.war/WEB-INF/server-config.wsdd

[ul]
[li]/WebServices/6.0.0/design/assembly/assembly.wsdl[/li][li]/WebServices/6.0.0/design/content/content.wsdl[/li][li]/WebServices/6.0.0/design/security/security.wsdl[/li][li]/WebServices/6.0.0/design/system/system.wsdl[/li][li]/WebServices/6.0.0/design/ui/ui.wsdl[/li][/ul]

Each WSDL file imports two schemas at relative paths:
[ul]
[li]…/faults.xsd[/li][li]and a XSD file with the same filename as the wsdl (e.g. system.xsd)[/li][/ul]

Developers attempting to use the provided WSDLs will encounter errors since these schemas are not available at the “relative path.” A request to http://localhost:9992/Rhythmyx/webservices/contentSOAP?wsdl will not deliver the expected behavior. From tests a developer would have to copy the wsdl and xsd files to the development computer, and reference these local files instead of Axis provided WSDLs.

Seems that this problem has been around in our community as well as others:
[ul]
[li]http://forum.percussion.com/archive/index.php/t-153.html[/li][li]https://issues.apache.org/jira/browse/AXIS2-1790[/li][/ul]

Has anyone else been impacted by this issue?

Yup. I believe I came up with the same solution (copy the files locally and reference those).

Filed a TS incident earlier this year but it was closed saying that this was the best solution. This solution has created some headaches in my experience with releasing projects that require SOAP interaction as I have to educate implementors on these additional steps. I don’t think this solution is how it is supposed to be.