[
https://issues.jboss.org/browse/JBWS-4087?page=com.atlassian.jira.plugin....
]
Nico Schlebusch edited comment on JBWS-4087 at 6/27/18 6:22 AM:
----------------------------------------------------------------
Hi [~rsearls]
I agree there can't be a generic solution and your use case for not doing it is valid.
What about doing the url rewrite when there is no absolute path/protocol included in the
schemaLocation URL? The bug report shows the rewritten URL's. The actual source WSDL
and XSD make use of a relative path. The source WSDL (packaged as part of the application)
contains something like:
{code:xml}
<xs:import namespace="http://example.co.za/claim/zmf"
schemaLocation="ZietoClaim_2_1.xsd"/>
{code}
And the referenced source XSD:
{code:xml}
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes"
schemaLocation="zmf_dt_2_1.xsd" />
<xsd:import namespace="http://example.co.za/common/datatypes"
schemaLocation="zdt_1_2.xsd" />
{code}
Alternatively, what if the schemaLocation URL uses the {{jbossws.undefined.host}}
variable/placeholder (something like it) for forcing the same rewrite rules that are
applied to the SOAP address location? Maybe something like:
{code:xml}
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes"
schemaLocation="{jbossws.undefined.host}/zmf_dt_2_1.xsd" />
<xsd:import namespace="http://example.co.za/common/datatypes"
schemaLocation="{jbossws.undefined.host}/zdt_1_2.xsd" />
{code}
I have no idea how to test for this. I can perhaps see if I can create a test case. Where
is the best place for a test case?
Here
[
https://github.com/jbossws/jbossws-cxf/tree/master/modules/testsuite/cxf-...]
using the bug number as a package name?
Is there any documentation available with pointers that could make it easier to write the
test case?
was (Author: nicoschl):
Hi [~rsearls]
I agree there can't be a generic solution and your use case for not doing it is valid.
What about doing the url rewrite when there is no absolute path/protocol included in the
schemaLocation URL? The bug report shows the rewritten URL's. The actual source WSDL
and XSD make use of a relative path. The source WSDL (packaged as part of the application)
contains something like:
{code:xml}
<xs:import namespace="http://example.co.za/claim/zmf"
schemaLocation="ZietoClaim_2_1.xsd"/>
{code}
And the referenced source XSD:
{code:xml}
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes"
schemaLocation="zmf_dt_2_1.xsd" />
<xsd:import namespace="http://example.co.za/common/datatypes"
schemaLocation="zdt_1_2.xsd" />
{code}
Alternatively, what if the schemaLocation URL uses the `jbossws.undefined.host`
variable/placeholder (something like it) for forcing the same rewrite rules that are
applied to the SOAP address location? Maybe something like:
{code:xml}
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes"
schemaLocation="{jbossws.undefined.host}/zmf_dt_2_1.xsd" />
<xsd:import namespace="http://example.co.za/common/datatypes"
schemaLocation="{jbossws.undefined.host}/zdt_1_2.xsd" />
{code}
I have no idea how to test for this. I can perhaps see if I can create a test case. Where
is the best place for a test case?
Here
[
https://github.com/jbossws/jbossws-cxf/tree/master/modules/testsuite/cxf-...]
using the bug number as a package name?
Is there any documentation available with pointers that could make it easier to write the
test case?
SOAP address rewrite for wsdl-uri-scheme=https for nested XML schema
documents (XSD) referenced by the WSDL behind reverse proxy
--------------------------------------------------------------------------------------------------------------------------------
Key: JBWS-4087
URL:
https://issues.jboss.org/browse/JBWS-4087
Project: JBoss Web Services
Issue Type: Bug
Components: jbossws-cxf
Affects Versions: jbossws-cxf-5.1.5.Final
Environment: Wildfly 10
JBossWS 5.1.5-Final
Reporter: Nico Schlebusch
Assignee: R Searls
Labels: JBossWS
Fix For: jbossws-cxf-5.2.2.Final
We have Wildfly 10 configured behind NGINX as a reverse proxy for handling the SSL
requirements of the web service. Wildfly serves everything as plain HTTP and NGINX handles
the HTTPS side of the request. The webservices subsystem is configured to rewrite the uri
using https schema. The XSD schema location referenced inside the WSDL is rewritten to use
https. However, any other XSD's scheme location that is referenced by the first XSD is
not changed to use https.
The URI rewriting for the SOAP address and the schema location of the XSD included in the
WSDL works correctly.
{{<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://example.systems/webservices/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:ns1="http://example.co.za/claim/zmf"
attributeFormDefault="unqualified" elementFormDefault="unqualified"
targetNamespace="http://example.systems/webservices/">
<xs:import namespace="http://example.co.za/claim/zmf"
schemaLocation="https://dev.example.ws:8081/webservices/Claim?xsd=ZietoClaim_2_1.xsd"/>
<!-- xml omitted -->
<wsdl:service name="ClaimService">
<wsdl:port binding="tns:ClaimServiceSoapBinding"
name="ClaimWSPort">
<soap12:address
location="https://dev.example.ws:8081/webservices/ZMF"/>
</wsdl:port>
</wsdl:service>}}
The XSD referenced inside the WSDL contains 2 more import statements to import 2 more
XSD's. This is however where the problem starts. In the extract below you will notice
that the schema location uses http and not https for the other 2 XSD's.
{{<?xml version='1.0' encoding='UTF-8'?>
<xsd:schema xmlns:zdt="http://example.co.za/claim/zmf/datatypes"
xmlns:zcdt="http://example.co.za/common/datatypes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://example.co.za/claim/zmf" elementFormDefault="qualified"
targetNamespace="http://example.co.za/claim/zmf">
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes"
schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zmf_dt_2_1.xsd"/>
<xsd:import namespace="http://example.co.za/common/datatypes"
schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zdt_1_2.xsd"/>
}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)