I'd really like to deal with this more comprehensively.
Could you possibly post the entire WSDL?
On Thu, May 22, 2008 at 3:04 PM, GlennS <[EMAIL PROTECTED]> wrote:
>
> 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.
>
>
