Dan, I think that he started with Aegis and then later wandered to Metro for comparison purposes, and I also think that there is indeed an xmime:base64binary that I ran into when I was tweaking Aegis MTOM.
--benson On Wed, May 21, 2008 at 5:11 PM, Daniel Kulp <[EMAIL PROTECTED]> 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 > > > > >
