start is optional on Multipart/Related - if present it tells which MIME
part is the root part and if absent the first MIME part in the
Multipart/Related structure is the root part. Since JAXWS reponse has no
start parameter and the first part is the root so .NET should be taking
it alright.
From the error it looks that .NET client is not expecting an Mtom
encoded response can you check .net client configuration to see if its
configured for Mtom Encoded endpoint?
-vivek.
Florian Rengers wrote:
>
> Hi,
>
> I wrote a Service based on the Java-Technology JAX-WS which provides
> documents MTOM encoded and I wrote a consumer-client in c#.NET.
>
> On client-side I get an exception during deserialisation the
> response-message:
>
> System.InvalidOperationException
> Client found response content type of
> 'Multipart/Related; type=\"application/xop+xml\";
> boundary=\"----=_Part_0_24598445.1143476873406\";
> start-info=\"text/xml\"',
> but expected 'text/xml'.
>
> I sniffed the in- and outcomming messages. Here is the JAX-WS
> response(shorted):
>
> ***************************************************************************
> Server: Apache-Coyote/1.1
> Set-Cookie: JSESSIONID=6156A549140745D2AD142A1F826387A4; Path=/geoengine
> Content-Type: Multipart/Related; type="application/xop+xml";
> boundary="----=_Part_2_18504142.1143467055109"; start-info="text/xml"
> Content-Length: 59571
> Date: Mon, 27 Mar 2006 13:44:15 GMT
>
> ------=_Part_2_18504142.1143467055109
> Content-Type: application/xop+xml; type="text/xml"; charset=utf-8
>
> <XML-RESPONSE>
> ------=_Part_2_18504142.1143467055109
> Content-Type: application/octet-stream
> Content-ID: <dddf4909-f6ad-4be5-8f2e-b2f3351ebf54_at_www.grit.de
> <mailto:dddf4909-f6ad-4be5-8f2e-b2f3351ebf54_at_www.grit.de>>
> Content-transfer-encoding: binary
>
> [BINARY DATA]
>
> ------=_Part_2_18504142.1143467055109--
> ***************************************************************************
>
> The only significant difference between .NET request and JAX-WS
> response is that the .NET request has an additional property "start"
> in its content-header which links to the message-part and "charset" is
> set to "utf-8".
>
> Could this be the reason for the fault?
>
> Best Regards
>
> Florian
>
>
--
Vivek Pandey
Web Services Standards and Technologies
Sun Microsystems Inc.