There were some changes to the MTOM stuff lately.. Try the latest nightly build and let us know the result..
~Thilina On 9/7/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Sure. Please let us know. If you need another wsdl to compare, please take at the xmime wsdl here: http://www.wso2.net/articles/axis2/java/2006/08/10/binary-with-adb On 9/7/06, Jay Gillibrand <[EMAIL PROTECTED]> wrote: > I'll try the new nightly build soon for the first problem. I'm using > ADB, since that's the default--I don't have a preference at this > point. > > Here's the XSD section of the WSDL for the operation I'm calling > (downloadAttachment). The rest of the WSDL isn't very > intereting--standard doc-literal messages, bindings, etc.: > > <s:element name="downloadAttachment"> > <s:complexType> > <s:sequence> > <s:element name="attachmentId" type="s:string"/> > </s:sequence> > </s:complexType> > </s:element> > > <s:element name="downloadAttachmentResponse"> > <s:complexType> > <s:sequence> > <s:element name="attachmentContents" type="s:base64Binary" > xmime:expectedContentTypes="application/binary"/> > </s:sequence> > </s:complexType> > </s:element> > > And here's the response I get back: > > HTTP/1.1 200 OK > Date: Thu, 07 Sep 2006 01:48:47 GMT > Server: Jetty/5.1.6 (Windows XP/5.1 x86 java/1.5.0_08 > Content-Type: multipart/related; type="application/xop+xml"; > start="<[EMAIL PROTECTED]>"; start-info="text/xml"; > boundary="----=_Part_9_5050494.1157593727524" > Transfer-Encoding: chunked > > 28c > > ------=_Part_9_5050494.1157593727524 > Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" > Content-Transfer-Encoding: 8bit > Content-ID: <[EMAIL PROTECTED]> > > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body><ns2:downloadAttachmentResponse > xmlns:ns2="http://www.telelogic.com/change/types"><attachmentContents><xop:Include > xmlns:xop="http://www.w3.org/2004/08/xop/include" > href="cid:115759372752410-1321599588@"/></attachmentContents></ns2:downloadAttachmentResponse></soap:Body></soap:Envelope>b5 > > ------=_Part_9_5050494.1157593727524 > Content-Type: application/octet-stream > Content-Transfer-Encoding: binary > Content-ID: <115759372752410-1321599588@> > > this is an attachment > 2a > > ------=_Part_9_5050494.1157593727524-- > > 0 > > On 9/7/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > that was build break for the mismatched if/else which i fixed > > yesterday. Please try a new nightly. > > > > -- dims > > > > On 9/7/06, Jay Gillibrand <[EMAIL PROTECTED]> wrote: > > > I tried the nightly and had two problems. First, one of the methods in > > > the stub wouldn't even compile since it was filled with mismatched ifs > > > and elses. Since it wasn't related to the download method I'm calling, > > > I just commented it out for now. > > > > > > Second, the stub for the download method still didn't work--but it was > > > close. My Soap response payload looks kinds like (wrapped > > > doc-literal): > > > > > > <downloadFileResponse> > > > <contents> > > > <Include href="..."> > > > ... > > > > > > The generated stub gets to the "contents" element and checks if it is > > > text or an "Include" element. It's neither, so it exceptions right > > > there. If I edit the stub to include an extra call to read.next() to > > > skip the "contents" element, it then finds the "Include" and > > > everything handles the response as expected: the file is downloaded. > > > > > > Basically it seems like the code generator in 1.0 can't generate stubs > > > for MTOM at all. The nightly build is getting closer it, but still > > > produces unusable code without a lot of tweaking. Anything I'm > > > missing? Does Axis 1 handle MTOM? > > > > > > -Jay > > > > > > > > > On 9/6/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > > Please use a nightly build of Axis2. > > > > > > > > Options options = myStub._getServiceClient().getOptions(); > > > > options.setProperty(org.apache.axis2.Constants.Configuration.ENABLE_MTOM, > > > > Boolean.TRUE); > > > > > > > > -- dims > > > > > > > > On 9/6/06, Jay Gillibrand <[EMAIL PROTECTED]> wrote: > > > > > I'm calling an XFire based web service that is using MTOM to return > > > > > attachments. Tracing the actual HTTP request I can see the response > > > > > looks like what I'd expect, but Axis2 fails to parse the results. > > > > > > > > > > The problem _seems_ to be that my Axis2 client stubs are expecting the > > > > > attachments to be inlined as base 64 in the Soap envelope, that is, > > > > > they are looking for a text element under the <attachmentContents> > > > > > element in the response. The actual response has an <xop:Include> > > > > > element there that refers to the data in another MIME section. > > > > > > > > > > Is there something that I need to do to get the stubs to recongnize > > > > > MTOM attachments? The stubs appear to be completely ignorant of MTOM > > > > > right now. The web site says clients automatically handle MTOM > > > > > attachments... > > > > > > > > > > -Jay > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) > > > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "May the SourcE be with u" http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
