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)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to