[
https://issues.apache.org/jira/browse/SYNAPSE-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated SYNAPSE-905:
------------------------------------
Description:
According to the WSDL generated by Axis2, SimpleStockQuoteService uses two
namespaces (i.e. wsdl:types contains two xs:schema elements):
http://services.samples and http://services.samples/xsd. Responses from
SimpleStockQuoteService use these two namespaces as expected. Unfortunately
SimpleStockQuoteService is a POJO service and for this type of services, Axis2
doesn't check the namespaces used in request messages.
There are multiple samples that send messages to SimpleStockQuoteService that
don't conform to the WSDL. E.g. sample 158 sends the following SOAP request:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body>
<ns0:getQuote xmlns:ns0="http://services.samples";>
<ns1:request xmlns:ns1="http://services.samples";>
<ns2:symbol xmlns:ns2="http://services.samples";>IBM</ns2:symbol>
</ns1:request>
</ns0:getQuote>
</soapenv:Body>
</soapenv:Envelope>
This message doesn't conform to the WSDL of SimpleStockQuoteService because the
"symbol" element is expected to be in the http://services.samples/xsd
namespace, not in http://services.samples.
Even the code of the test client (see the StockQuoteHandler class) uses the
wrong namespaces, as shown in the following piece of code:
/**
* Create a new quote request with a body as follows
* <m:GetQuote xmlns:m="http://services.samples";>
* <m:request>
* <m:symbol>IBM</m:symbol>
* </m:request>
* </m:GetQuote>
* @param symbol the stock symbol
* @return OMElement for SOAP body
*/
public static OMElement createStandardQuoteRequest(String symbol, int
itrCount) {
OMFactory factory = OMAbstractFactory.getOMFactory();
OMNamespace ns =
factory.createOMNamespace("http://services.samples";, "m0");
OMElement getQuote = factory.createOMElement("getQuote", ns);
for (int i =0; i<itrCount; i++) {
OMElement request = factory.createOMElement("request", ns);
OMElement symb = factory.createOMElement("symbol", ns);
request.addChild(symb);
getQuote.addChild(request);
symb.setText(symbol);
}
return getQuote;
}
Sample 15 is also interesting:
<in>
<enrich>
<source type="custom"
xpath="//m0:getQuote/m0:request/m0:symbol/text()"
xmlns:m0="http://services.samples"/>
...
</enrich>
...
</in>
<out>
...
<enrich>
<source type="custom"
xpath="//ns:getQuoteResponse/ns:return/ax21:lastTradeTimestamp"
xmlns:ns="http://services.samples";
xmlns:ax21="http://services.samples/xsd"/>
...
</enrich>
…
</out>
One can see that the sample uses incorrect namespaces to extract data from the
request message (because the test client uses the wrong namespace for the
"symbol" element), but uses the correct ones to extract data from the response
message (because the response is produced by Axis2 and conforms to the WSDL).
Although these namespace mismatches don't trigger any errors when executing the
samples (because as noted above, Axis2 doesn't check namespaces for POJO
services), we still need to fix them:
* Obviously, distributing samples that use messages not conforming to the WSDL
of the target service doesn't give a good impression to end users.
* There is a permanent risk that correcting the namespaces at one place will
breaks things in other places.
The root cause of the issue seems to be that between Axis2 1.4 and 1.5, the
default conventions for namespaces used by POJO services have changed. In fact,
in Synapse 1.2, the WSDL for SimpleStockQuoteService still used a single
namespace (although that was http://services.samples/xsd and not
http://services.samples).
There are two solutions for this issue:
(1) Leave the SimpleStockQuoteService as is and change the samples. Since most
of the samples were originally written for the old conventions, this will
require significant work. In addition, it will not be easy to identify the
samples that need to be fixed.
(2) Change the configuration of SimpleStockQuoteService so that it uses a
single namespace again by adding the following to the services.xml file:
<schema>
<mapping package="samples.services"
namespace="http://services.samples"/>
</schema>
This makes it significantly easier to fix the samples (it is easier to go from
two namespaces to one namespace than the other way round). It will also be easy
to identify the samples that need to be fixed, simply by looking for
occurrences of http://services.samples/xsd.
was:
Sample 158 sends the following SOAP message to the target service
(SimpleStockQuoteService):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body>
<ns0:getQuote xmlns:ns0="http://services.samples";>
<ns1:request xmlns:ns1="http://services.samples";>
<ns2:symbol xmlns:ns2="http://services.samples";>IBM</ns2:symbol>
</ns1:request>
</ns0:getQuote>
</soapenv:Body>
</soapenv:Envelope>
This message doesn't conform to the WSDL of SimpleStockQuoteService because the
"symbol" element is expected to be in the http://services.samples/xsd
namespace, not in http://services.samples. The service only accepts the message
because Axis2 POJO services are very lenient when it comes to namespaces...
Summary: Namespace mismatch in samples that use SimpleStockQuoteService
(was: Sample 158 produces SOAP message that doesn't conform to the WSDL of the
target service)
> Namespace mismatch in samples that use SimpleStockQuoteService
> --------------------------------------------------------------
>
> Key: SYNAPSE-905
> URL: https://issues.apache.org/jira/browse/SYNAPSE-905
> Project: Synapse
> Issue Type: Bug
> Components: Documentation
> Reporter: Andreas Veithen
> Priority: Minor
>
> According to the WSDL generated by Axis2, SimpleStockQuoteService uses two
> namespaces (i.e. wsdl:types contains two xs:schema elements):
> http://services.samples and http://services.samples/xsd. Responses from
> SimpleStockQuoteService use these two namespaces as expected. Unfortunately
> SimpleStockQuoteService is a POJO service and for this type of services,
> Axis2 doesn't check the namespaces used in request messages.
> There are multiple samples that send messages to SimpleStockQuoteService that
> don't conform to the WSDL. E.g. sample 158 sends the following SOAP request:
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
> <soapenv:Body>
> <ns0:getQuote xmlns:ns0="http://services.samples";>
> <ns1:request xmlns:ns1="http://services.samples";>
> <ns2:symbol xmlns:ns2="http://services.samples";>IBM</ns2:symbol>
> </ns1:request>
> </ns0:getQuote>
> </soapenv:Body>
> </soapenv:Envelope>
> This message doesn't conform to the WSDL of SimpleStockQuoteService because
> the "symbol" element is expected to be in the http://services.samples/xsd
> namespace, not in http://services.samples.
> Even the code of the test client (see the StockQuoteHandler class) uses the
> wrong namespaces, as shown in the following piece of code:
> /**
> * Create a new quote request with a body as follows
> * <m:GetQuote xmlns:m="http://services.samples";>
> * <m:request>
> * <m:symbol>IBM</m:symbol>
> * </m:request>
> * </m:GetQuote>
> * @param symbol the stock symbol
> * @return OMElement for SOAP body
> */
> public static OMElement createStandardQuoteRequest(String symbol, int
> itrCount) {
> OMFactory factory = OMAbstractFactory.getOMFactory();
> OMNamespace ns =
> factory.createOMNamespace("http://services.samples";, "m0");
> OMElement getQuote = factory.createOMElement("getQuote", ns);
> for (int i =0; i<itrCount; i++) {
> OMElement request = factory.createOMElement("request", ns);
> OMElement symb = factory.createOMElement("symbol", ns);
> request.addChild(symb);
> getQuote.addChild(request);
> symb.setText(symbol);
> }
> return getQuote;
> }
> Sample 15 is also interesting:
> <in>
> <enrich>
> <source type="custom"
> xpath="//m0:getQuote/m0:request/m0:symbol/text()"
> xmlns:m0="http://services.samples"/>
> ...
> </enrich>
> ...
> </in>
> <out>
> ...
> <enrich>
> <source type="custom"
>
> xpath="//ns:getQuoteResponse/ns:return/ax21:lastTradeTimestamp"
> xmlns:ns="http://services.samples";
> xmlns:ax21="http://services.samples/xsd"/>
> ...
> </enrich>
> …
> </out>
> One can see that the sample uses incorrect namespaces to extract data from
> the request message (because the test client uses the wrong namespace for the
> "symbol" element), but uses the correct ones to extract data from the
> response message (because the response is produced by Axis2 and conforms to
> the WSDL).
> Although these namespace mismatches don't trigger any errors when executing
> the samples (because as noted above, Axis2 doesn't check namespaces for POJO
> services), we still need to fix them:
> * Obviously, distributing samples that use messages not conforming to the
> WSDL of the target service doesn't give a good impression to end users.
> * There is a permanent risk that correcting the namespaces at one place will
> breaks things in other places.
> The root cause of the issue seems to be that between Axis2 1.4 and 1.5, the
> default conventions for namespaces used by POJO services have changed. In
> fact, in Synapse 1.2, the WSDL for SimpleStockQuoteService still used a
> single namespace (although that was http://services.samples/xsd and not
> http://services.samples).
> There are two solutions for this issue:
> (1) Leave the SimpleStockQuoteService as is and change the samples. Since
> most of the samples were originally written for the old conventions, this
> will require significant work. In addition, it will not be easy to identify
> the samples that need to be fixed.
> (2) Change the configuration of SimpleStockQuoteService so that it uses a
> single namespace again by adding the following to the services.xml file:
> <schema>
> <mapping package="samples.services"
> namespace="http://services.samples"/>
> </schema>
> This makes it significantly easier to fix the samples (it is easier to go
> from two namespaces to one namespace than the other way round). It will also
> be easy to identify the samples that need to be fixed, simply by looking for
> occurrences of http://services.samples/xsd.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
