[ 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.