[
https://issues.apache.org/jira/browse/TUSCANY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600586#action_12600586
]
Simon Nash commented on TUSCANY-1713:
-------------------------------------
I tried this with the new runtime Java2WSDL generator. As part of the check-in
to enable the new generator, I had fixed a problem in the test case where the
namespace of the AccountDataService service endpoint interface
("http://accountdata.services.account.bigbank";) did not match the namespace in
the WSDL and the generated SDO wrapper classes
("http://www.bigbank.com/account";). I fixed this by adding the annotation
@WebService(targetNamespace="http://www.bigbank.com/account";) to the
AccountDataService interface so that the namespaces are all consistent.
With this namespace fix in the test case and the new Java2WSDL runtime
generator (case 1), the SOAP request message is
<p0:createAccount
xmlns:p0="http://www.bigbank.com/account";><customerProfile><firstName>petra</firstName><lastName>A</lastName><address>home</address><email>[EMAIL
PROTECTED]</email><loginID>petra</loginID><password>ant</password><id>1</id></customerProfile></p0:createAccount>
and the response message is
<p0:createAccountResponse
xmlns:p0="http://www.bigbank.com/account";><customerProfile><firstName>petra</firstName><lastName>A</lastName><address>home</address><email>[EMAIL
PROTECTED]</email><loginID>petra</loginID><password>ant</password><id>1</id></customerProfile></p0:createAccountResponse>
which all looks clean and correct, and is marshalled and unmarshalled correctly
by the runtime.
If I remove the namespace fix from the test case (case 2), thus creating a
"user error" situation with inconsistent namespaces, the SOAP request message
changes to
<_ns_:createAccount
xmlns:_ns_="http://accountdata.services.account.bigbank/";><p0:arg0
xmlns:p0="http://accountdata.services.account.bigbank/";
xmlns:p1="http://www.bigbank.com/account";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:type="p1:CustomerProfileData"><firstName>petra</firstName><lastName>A</lastName><address>home</address><email>[EMAIL
PROTECTED]</email><loginID>petra</loginID><password>ant</password><id>1</id></p0:arg0><arg1
xmlns="http://accountdata.services.account.bigbank/";>false</arg1><arg2
xmlns="http://accountdata.services.account.bigbank/";>false</arg2></_ns_:createAccount>
and the response message remains as previously, i.e.,
<p0:createAccountResponse
xmlns:p0="http://www.bigbank.com/account";><customerProfile><firstName>petra</firstName><lastName>A</lastName><address>home</address><email>[EMAIL
PROTECTED]</email><loginID>petra</loginID><password>ant</password><id>1</id></customerProfile></p0:createAccountResponse>
There is a problem/inconsistency here. The request message is using the
namespace "http://accountdata.services.account.bigbank/"; for the request
wrapper, so it is taking the namespace from the SEI and the generated WSDL.
However, the response wrapper is using the namespace
"http://www.bigbank.com/account";, so it is taking the namespace from the SDO
wrapper and not from the SEI or generated WSDL.
The service is able to unmarshal the request, even though the SOAP namespace
for the request wrapper doesn't match the SDO request wrapper class on the
service side. However, the client isn't able to unmarshal the response
correctly (it creates a generic dynamic SDO for customerProfile).
It appears that
a) request marshalling and unmarshalling is using the WSDL namespace for
wrappers and ignoring SDO wrapper classes if they exist
b) request marshalling and unmarshalling is using xsi:type to correctly
identify the namespace and local name of the wrapped data type
c) response marshalling is creating wrappers using SDO wrapper classes if they
exist, even if these have a namespace that doesn't match the WSDL
d) response marshalling is not using xsi:type to identify the wrapped data
type, causing unmarshalling to fail
> The WSDL-less feature doesn't honor the XSD type information in the SDO
> parameter/return type
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1713
> URL: https://issues.apache.org/jira/browse/TUSCANY-1713
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Axis Binding Extension
> Affects Versions: Java-SCA-Next
> Reporter: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> In the itest-wsdless test case testClient1b2a3a4a, we use interface.java for
> the client side and interface.wsdl for the service side. Generated SDO are
> used for both the client and service side. But the current java2wsdl
> conversion creates a similar but not equivalent WSDL as the service side. As
> a result, the outbound call flows the non-comforming XML in the body of the
> SOAP message. We have to work around the unwrapping logic on the service side
> to tolerate the incoming data.
> <_ns_:createAccount
> xmlns:_ns_="http://accountdata.services.account.bigbank";><param0
> xmlns="http://accountdata.services.account.bigbank";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:p0="commonj.sdo"
> xmlns:p1="http://www.bigbank.com/account";
> xsi:type="p1:CustomerProfileData"><firstName
> xmlns="">petra</firstName><lastName xmlns="">A</lastName><address
> xmlns="">home</address><email xmlns="">[EMAIL PROTECTED]</email><loginID
> xmlns="">petra</loginID><password xmlns="">ant</password><id
> xmlns="">1</id></param0><_ns_:param1>false</_ns_:param1><_ns_:param2>false</_ns_:param2></_ns_:createAccount>
> Please note the wrapper and child elements hav
> On the response path, with the SDO --> OMElement transformation, it's legal
> to not generate xsi:type for the child elements. But it will cause problems
> on the client side as it has to take the response child element by position
> even if the QName doesn't match and there is no valid xsi:type to help the
> deserilization of SDO data.
> <p0:createAccountResponse
> xmlns:p0="http://www.bigbank.com/account";><customerProfile
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:_typens_="http://account.bigbank.com/xsd";
> xsi:type="_typens_:CustomerProfileData"><firstName>petra</firstName><lastName>A</lastName><address>home</address><email>[EMAIL
>
> PROTECTED]</email><loginID>petra</loginID><password>ant</password><id>1</id></customerProfile></p0:createAccountResponse>
> Please note the xsi:type is not correct (if we try to derive it from the
> client side).
> The key issue here is that we don't honor the XSD types behind the complex
> parameter/return types even we know the XSD type from databinding
> introspections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
