cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DTaylor <>
Subject Unexpected element on return from STS (CXF 2.6.2)
Date Fri, 07 Sep 2012 18:59:49 GMT
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, (, 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.


Dan. exception.txt sts.wsdl 

View this message in context:
Sent from the cxf-user mailing list archive at

View raw message