Re: Re: MTOM attachments from XFire
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:Bodyns2:downloadAttachmentResponse xmlns:ns2=http://www.telelogic.com/change/types;attachmentContentsxop:Include xmlns:xop=http://www.w3.org/2004/08/xop/include; href=cid:115759372752410-1321599588@//attachmentContents/ns2:downloadAttachmentResponse/soap:Body/soap:Envelopeb5 --=_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
Re: Re: MTOM attachments from XFire
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:Bodyns2:downloadAttachmentResponse xmlns:ns2=http://www.telelogic.com/change/types;attachmentContentsxop:Include xmlns:xop=http://www.w3.org/2004/08/xop/include; href=cid:115759372752410-1321599588@//attachmentContents/ns2:downloadAttachmentResponse/soap:Body/soap:Envelopeb5 --=_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,
Re: MTOM attachments from XFire
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]
Re: Re: MTOM attachments from XFire
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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: MTOM attachments from XFire
Hi Jay, The web site says clients automatically handle MTOM attachments... Yes.. It's true.. Client identifies and creates a OMText object in the place of XOP:Include element... Configuration Dims has mentioned is usefull when sending MTOM attachements. What's the data binding framework you are using.. XMLBeans or ADB.. Please post your WSDL and if possible message snapshots too... Thilina 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] - 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]
