cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GlennS <GSchm...@harmanbecker.com>
Subject Re: MTOM WSDL For Gsoap and CXF
Date Tue, 27 May 2008 12:45:03 GMT

Sorry, but unfortunately it would be tough for me to post the entire WSDL
since this is a bit of proprietary, closed-door system. The pertinent parts
of it that I think you'd be interested in, however, are fairly
straightforward to re-create with GSOAP and soapcpp2.exe. Ultimately,
GSOAP's author didn't choose the same protocol/nomenclature as the rest of
the Java world for signaling MTOM attachments in the WSDL. I don't believe
his approach is wrong or strictly incorrect from a standards perspective
(although I'm no expert here), but apparently not what the Java WSDL
toolsmiths were expecting.

I've attached a condensed WSDL with putChunk/getChunk methods where the
"chunk" is an MTOM/XOP attachment. This is basically what I started with
before I started tweaking my definitions to make them Java "compliant". I
also have attached my GSOAP header file (.h) that is used (via soapcpp2.exe)
to generate the WSDL. I hope this is what you are asking for . . .

Glenn




Benson Margulies-4 wrote:
> 
> 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 <GSchmott@harmanbecker.com> 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
>>> dkulp@apache.org
>>> 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.
>>
>>
> 
> 
http://www.nabble.com/file/p17489608/Headunit.h Headunit.h 
http://www.nabble.com/file/p17489608/HeadunitRemoteServices.wsdl
HeadunitRemoteServices.wsdl 
-- 
View this message in context: http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17489608.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message