On May 20, 2008, at 4:30 PM, GlennS wrote:
Unforunately, all the Java tools I've run across do not understand
this (or
do not realize this request/response uses MTOM). In order to get the
Java
WSDL parsers to correctly interpret this WSDL file I have to modify
the type
to:
<complexType name="FileChunk">
<annotation>
<documentation>contains a MIME attachment</documentation>
</annotation>
<sequence>
<element name="chunk" type="xmime:base64Binary"
xmime:expectedContentType="application/octet-stream"/>
</sequence>
</complexType>
Actually, normally you would use:
<element name="chunk" type="xdd:base64Binary"
xmime:expectedContentType="application/octet-stream"/>
and not put the base64Binary in the xmime ns, but it doesn't really
matter.
REQUEST
=======
POST / HTTP/1.1
SOAPAction: ""
Accept: application/soap+xml, multipart/related, text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2
Content-Type:
multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
+xml";action=""
User-Agent: Java/1.6.0_06
Host: 127.0.0.1:6667
Connection: keep-alive
Content-Length: 623
--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
Content-Type: application/xop+xml;charset=utf-8;type="application/
soap+xml"
Content-Transfer-Encoding: binary
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope";>
<S:Body>
<ns3:getFileChunk xmlns:ns5="http://www.w3.org/2004/08/xop/include
"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime";
xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
xmlns:ns1="http://www.w3.org/2003/05/soap-encoding";>
<filename>dw.log</filename>
<offset>0</offset>
<length>100000</length>
</ns3:getFileChunk>
</S:Body>
</S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
Which is completely correct and allowed.
Unfortunately, it doesn't appear the Metro client correctly parses the
returned file chunk. I get a chunk type back but it contains no data
(and
there are no exceptions either). One thing to notice between the GSOAP
client call and the Metro client call is that the HTTP contentType
for GSOAP
request is:
Content-Type: application/soap+xml; charset=utf-8
And the contentType for the Metro call is:
Content-Type:
multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
+xml";action=""
I'm no SOAP expert but this initially caused my GSOAP server problems
because it interprets the request as having an incoming MIME
component.
Well, the soap message itself is in a mime component. That's allowed.
So, at this point I am stuck. I can't figure out how to force the
Java Metro
Client to consume the returned attachment. I'm not sure what it's
looking
for in the stream or if I haven't enabled a particular option.
Can anyone tell me what's going on here? It looks like (as far as
MTOM/XOP
methods) are concerned, the GSOAP and the Java world are
incompatible. My
other non-MTOM methods work fine. I just can't see how to get MTOM
to work
between GSOAP and the Java toolkits.
Well, I cannot really help too much with Metro. Have you tried
CXF? If you have a server up and running someplace, I could
potentially give it a quick try and see what happens.
Dan
One more note: I can use the SoapUI tools with the GSOAP WSDL file
to get
file chunks. Apparently this tool does not rely on an underlying
toolkit and
does the WSDL and request/response parsing itself.
Any help or suggestions would be appreciated!!!!!
Benson Margulies-4 wrote:
Perhaps more to the point, however, the error you sent indicates
that your
gsoap device is simply sending invalid XML. All the prefixes have
to be
defined, and the complaint is that 'xop:' is not defined. have you
used
logging to pull a complete copy of the XML off the wire?
--
View this message in context:
http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
