spring-projects
Improve the location and schema location transform feature [SWS-903]
Mauro Molinari opened SWS-903 and commented
Some related issues may be #588 and #654, but here I would like to give a more complete picture of what I personally would need.
IMHO Spring Web Services location and schema location transform feature is essential, but also very limited, especially when dealing with static WSDLs, where I would expect SWS to be stronger (since it promotes the "contract first" approach). Let me explain with a concrete real example.
I have to integrate my webapp with an external system. This external system requires my webapp to expose some web services and gives me the contract I have to publish in the form of a WSDL file and an imported XSD file. The WSDL file of course contains a fake location, while the schema location is a simple relative location that expects the XSD do be in the same place as the WSDL. I mean:
<soapbind:address location="http://fakedomain.com/MyService" />
and:
<xsd:import namespace="http://service/name/space/types" schemaLocation="MyXsdFile.xsd"/>
Ideally, I would like to expose this WSDL AS IS (i.e.: without touching it) and let SWS automatically change the locations for me so that when a client downloads the WSDL from my webapp, it contains URLs that can be handled by the MessageDispatcherServlet. So, if my webapp is published at http://mydomain.com/myapp and the MessageDispatcherServlet is mapped on "/ws/*", I would expect to see the following URLs being produced by SWS:
- http://mydomain.com/myapp/ws/MyService.wsdl (location)
- http://mydomain.com/myapp/ws/MyXsdFile.xsd (schema location)
However, currently this is what I see. The first difficulty I had is that, after declaring my WSDL as static:
<web-services:static-wsdl id="MyService"
location="classpath:/wsdl/MyService.wsdl" />
I could not find any equivalent <web-services:static-xsd> to publish the XSD, nor the <web-services:static-wsdl> has the ability to specify a nested <web-services:xsd> to tell SWS where the imported schemas could be found (like <web-services:dynamic-wsdl> has). Anyway, I discovered that I may declare a SimpleXsdSchema bean to point to the XSD, however an actual link between the WSDL and the XSD does not exist. This could be improved, maybe <web-services:static-wsdl> could take care of all of this and expose the XSD automatically.
Anyway, once both the WSDL and XSD are exposed, if I request my WSDL file as http://mydomain.com/myapp/ws/MyService.wsdl I see that the transformed location is: http://mydomain.com/TrasmissioneFatture, that is, as the documentation says, only the scheme, server name and host is changed, while context path and servlet mapping information is lost. On the other hand, since the original schema location is relative and without any leading slash, it's kept unmodified in the output WSDL file. If the client can resolve this relative URL, it will work (as long as the SimpleXsdSchema id is the same as the actual XSD file name), but it's more by chance that on purpose.
In short, I think the the location and schema location transform feature should be smart enough to produce links that can be handled back by the same MessageDispatcherServlet that apply such transformations, otherwise the generated URLs may be just wrong, unless I put some knowledge of the final deploy environment in the static WSDL file, which is something I would like to avoid (otherwise I wouldn't be using the "transform" feature at all).
Please note that Apache CXF, with its servlet, does exactly this.
Affects: 2.2.1
