I figured out how to work my GSOAP/Java mis-match problem after a lot of
effort and some helpful pointers along the way.
The currently documented (in the GSOAP user's guide) approach to enable
attachments is to specify an attachment type in your service header file
(diag.h) that you run soapcpp2.exe . . .
struct diag__FileChunk
{ _xop__Include xop__Include;
@char* xmime4__contentType;
};
Unfortunately, this generates the following complex type:
<complexType name="FileChunk">
<annotation>
<documentation>contains a MIME attachment</documentation>
</annotation>
<sequence>
<element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute ref="xmime4:contentType" use="optional"/>
</complexType>
Unfortunately none of the Java client generators understand this. Finally, I
found a solution (see the GSOAP forum if you're interested:
http://tech.groups.yahoo.com/group/gsoap/message/15680). You basically have
to redefine your MTOM type in a manner better understood (expected) by the
Java WSDL parsers.
Thanks for the offer of help. Hopefully my problems are behind me now.
dkulp wrote:
>
>
> 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
>
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17411311.html
Sent from the cxf-user mailing list archive at Nabble.com.
