done! http://opensource.atlassian.com/proj...browse/SWS-176
hopefully somebody can quickly fix it.
done! http://opensource.atlassian.com/proj...browse/SWS-176
hopefully somebody can quickly fix it.
The problem still exists in Spring-WS 1.0.2.
The namespace collition problem was also the point we hit as we built a second webservice.
Therefore, we set a unique target namespace for every webservice we deploy.
As long as the two webservices got no relation to each other, this isn't a problem.
But if you have to deploy another version of an existing webservice in parallel to the old one (e.g to not break other apps that use your service), this is not optimal.
Btw: The PayloadValidationInterceptor seems to accept schema file wildcards also:
<bean class="org.springframework.ws.soap.server.endpoint .interceptor.PayloadValidatingInterceptor">
<property name="schemas">
<list>
<value>/WEB-INF/ws/*.xsd</value>
</list>
</property>
<property name="validateRequest" value="true"/>
<property name="validateResponse" value="true"/>
</bean>
Last edited by robertoschwald; Dec 11th, 2007 at 09:50 AM.
We can not set a unique target namespace for every webservice, so we need a solution for that problem. Do anybody know how to use PayloadValidatingInterceptor with a set of schemas that share the same namespace?
The schema handling code Spring-WS's PayloadValidatingInterceptor depends on javax.xml.validation.Schema. The algorithm for multiple namespaces is described here: http://java.sun.com/j2se/1.5.0/docs/...sform.S ource[]), the "W3C XML Schema 1.0" part of that method specifically.
I ran into this problem too when using the PayloadValidatingInterceptor to validate against multiple schemas that were all in the same namespace. Due to what looks to be a vagueness in the spec or the JAXP implementation, there is some flakiness when validating multiple schemas with the same namespace.
For what it is worth, I was able to get past my problems by pointing my validating interceptor to a single xsd file that included all my schemas, and by avoiding using relative paths that used "../". This works fine now. I think the weirdness is in JAXP, not spring-ws.
BTW - Afterwards I found this link where someone else encountered basically the exact same problems I did. See: http://kontrawize.blogs.com/kontrawi...rouble-wit.htm
Fixing the link in my post: http://kontrawize.blogs.com/kontrawi...ouble-wit.html