[
https://issues.apache.org/jira/browse/TUSCANY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600714#action_12600714
]
Simon Nash commented on TUSCANY-1713:
-------------------------------------
Please ignore the second part of the above comment. My test was using
interface.wsdl on the service provider side, which explains the strange results
(I thought it was interface.java). I retried this "user error" test with
interface.java on the service provider side. The SOAP request was
<_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 was
<_ns_:createAccountResponse
xmlns:_ns_="http://accountdata.services.account.bigbank/";><p0:return
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:return></_ns_:createAccountResponse>
Both of these look correct to me.
> 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.
