Good day all, We recently moved to CXF 2.6.2 from 2.5.2, and previously we were able to communicate between a .NET STS and a Java client & service perfectly fine.
Once we upgraded, we are now getting the attached Unexpected element exception (exception.txt) in our integration tests. From what we can see in the standard, (http://www.w3.org/TR/wsdl#_soap%3abody), it appears as though CXF 2.6.2 is incorrectly assuming that with an operation style of document, there will be an element named IssueResult. With CXF 2.5.2 this worked as expected, with the RequestSecurityTokenResponseCollection being used, without a wrapping result value. Our interpretation comes specifically from the following portion from the provided link: * If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call. * If the operation style is document there are no additional wrappers, and the message parts appear directly under the SOAP Body element. The format which was accepted in CXF 2.5.2 is being returned from a Microsoft .NET STS. Does this interpretation differ from what the CXF interpretation is? I have also attached the .NET STS WSDL. Thanks, Dan. http://cxf.547215.n5.nabble.com/file/n5713722/exception.txt exception.txt http://cxf.547215.n5.nabble.com/file/n5713722/sts.wsdl sts.wsdl -- View this message in context: http://cxf.547215.n5.nabble.com/Unexpected-element-on-return-from-STS-CXF-2-6-2-tp5713722.html Sent from the cxf-user mailing list archive at Nabble.com.
