You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jay Gillibrand <ja...@gmail.com> on 2006/09/07 02:22:59 UTC
MTOM attachments from XFire
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Re: MTOM attachments from XFire
Posted by Thilina Gunarathne <cs...@gmail.com>.
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 <da...@gmail.com> 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 <ja...@gmail.com> 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="<so...@xfire.codehaus.org>"; 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: <so...@xfire.codehaus.org>
> >
> > <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 <da...@gmail.com> 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 <ja...@gmail.com> 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 <da...@gmail.com> 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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
"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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
catalina.policy (MBeanServer permission)
Posted by Martin Gainty <mg...@hotmail.com>.
Gentlemen-
I have a catalina.policy file which is over 100 lines long-
Thats *ok* but everytime I want to run one class I have to add another RuntimePermission for the accompanying jar..Same for DB access and any I/O
The most insidious line is the one that details permissions for MBeanServer
grant codeBase "file:${catalina.home}/-"
{
permission java.lang.RuntimePermission "getenv.CATALINA_HOME";
permission java.lang.RuntimePermission "setenv.CATALINA_HOME";
permission java.util.PropertyPermission "javax.management.MBeanServer", "read,write";
permission javax.management.MBeanServerPermission "*";
};
as you can see I want 2 operations for MBeanServer <read and write>
If I place either of these in the last parameter then axis errors out ungracefully
The first parameter i specify is * (for all MBeanServer operations) which includes the following permissions-
createMBeanServer
findMbeanServer
newMBeanServer
releaseMBeanServer
The second parameter specifies actions which must be null (say what..since when is NULL valid??)
Maybe I live in the bizarro world but should'nt we specify a non-null value for the second parameter such as read/write
Any clues on this issue or should I ping the engineers at Sun?
Thanks
Martin --
*********************************************************************
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
catalina.policy (MBeanServer permission)
Posted by Martin Gainty <mg...@hotmail.com>.
Gentlemen-
I have a catalina.policy file which is over 100 lines long-
Thats *ok* but everytime I want to run one class I have to add another RuntimePermission for the accompanying jar..Same for DB access and any I/O
The most insidious line is the one that details permissions for MBeanServer
grant codeBase "file:${catalina.home}/-"
{
permission java.lang.RuntimePermission "getenv.CATALINA_HOME";
permission java.lang.RuntimePermission "setenv.CATALINA_HOME";
permission java.util.PropertyPermission "javax.management.MBeanServer", "read,write";
permission javax.management.MBeanServerPermission "*";
};
as you can see I want 2 operations for MBeanServer <read and write>
If I place either of these in the last parameter then axis errors out ungracefully
The first parameter i specify is * (for all MBeanServer operations) which includes the following permissions-
createMBeanServer
findMbeanServer
newMBeanServer
releaseMBeanServer
The second parameter specifies actions which must be null (say what..since when is NULL valid??)
Maybe I live in the bizarro world but should'nt we specify a non-null value for the second parameter such as read/write
Any clues on this issue or should I ping the engineers at Sun?
Thanks
Martin --
*********************************************************************
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
Re: Re: MTOM attachments from XFire
Posted by Davanum Srinivas <da...@gmail.com>.
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 <ja...@gmail.com> 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="<so...@xfire.codehaus.org>"; 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: <so...@xfire.codehaus.org>
>
> <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 <da...@gmail.com> 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 <ja...@gmail.com> 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 <da...@gmail.com> 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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Re: MTOM attachments from XFire
Posted by Jay Gillibrand <ja...@gmail.com>.
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="<so...@xfire.codehaus.org>"; 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: <so...@xfire.codehaus.org>
<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 <da...@gmail.com> 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 <ja...@gmail.com> 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 <da...@gmail.com> 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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Re: MTOM attachments from XFire
Posted by Davanum Srinivas <da...@gmail.com>.
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 <ja...@gmail.com> 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 <da...@gmail.com> 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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Re: MTOM attachments from XFire
Posted by Thilina Gunarathne <cs...@gmail.com>.
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 <ja...@gmail.com> 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 <da...@gmail.com> 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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
"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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Re: MTOM attachments from XFire
Posted by Jay Gillibrand <ja...@gmail.com>.
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 <da...@gmail.com> 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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MTOM attachments from XFire
Posted by Davanum Srinivas <da...@gmail.com>.
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 <ja...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org