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 Clarence Dahlin <cl...@gmail.com> on 2005/12/21 09:37:46 UTC
Bug in Axis 1.3, base64Binary?
I've come across a somewhat puzzling problem. Could this be a bug or what am
I doing wrong?
I'm using Axis 1.3 final and generated the client stubs with the WSDL2Java
tool.
I'm using a modular WSDL, like this:
myWSDL.wsdl imports abstractwsdl.wsdl
abstractwsdl.wsdl imports calls.xsd
calls.xsd imports types.xsd
I have a simple type in types.xsd as base64Binary:
<xsd:simpleType name="sessionID">
<xsd:restriction base="xsd:base64Binary"/>
</xsd:simpleType>
It is refered to in calls.xsd:
<xsd:element name="createFederationExecution">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="federationExecutionName"
type="types:federationExecutionName"/>
<xsd:element name="fomDocumentDesignator"
type="types:fomDocumentDesignator"/>
<xsd:element name="sessionID" type="types:sessionID"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
If I do like that I end up sending this on the wire, using the stubs:
<sessionID>-17</sessionID><sessionID>78</sessionID><sessionID>93</sessionID><sessionID>-37</sessionID>
(and so on)
If I refer to base64Binary instead:
<xsd:element name="sessionID" type="xsd:base64Binary"/>
it works and I send this:
<sessionID xmlns="">705d28/1084c52a6e9//7ffe</sessionID>
Any thoughts on this?
regards,
Clarence
Re: Bug in Axis 1.3, base64Binary?
Posted by Clarence Dahlin <cl...@gmail.com>.
Is this the way it supposed to be?
I prefer to use types instead of elements in general since I believe it
should add a better OOP approach (reuse) . At the simple type level, as in
my example code, it shouldn't matter though.
If anyone knows I'm eager to be enlightened :-)
kind regards,
Clarence
On 1/16/06, Clarence Dahlin <cl...@gmail.com> wrote:
>
> Thank you Davanum.
> So many other things got in between so I didn't try this until now. It
> worked.
>
> I thought I'd post this so anyone else having the same problem knows it
> could solve their problem too.
>
> kind regards,
> Clarence
>
> On 12/21/05, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > did you try "ref" instead of "type"?
> >
> > On 12/21/05, Clarence Dahlin <cl...@gmail.com> wrote:
> > > WSDL style is document/literal wrapped by the way.
> > >
> > >
> > > On 12/21/05, Clarence Dahlin <clarence.pitch@gmail.com > wrote:
> > > > I've come across a somewhat puzzling problem. Could this be a bug or
> > what
> > > am I doing wrong?
> > > > I'm using Axis 1.3 final and generated the client stubs with the
> > WSDL2Java
> > > tool.
> > > >
> > > > I'm using a modular WSDL, like this:
> > > >
> > > > myWSDL.wsdl imports abstractwsdl.wsdl
> > > > abstractwsdl.wsdl imports calls.xsd
> > > > calls.xsd imports types.xsd
> > > >
> > > > I have a simple type in types.xsd as base64Binary:
> > > > <xsd:simpleType name="sessionID">
> > > > <xsd:restriction base="xsd:base64Binary"/>
> > > > </xsd:simpleType>
> > > >
> > > > It is refered to in calls.xsd:
> > > > <xsd:element name="createFederationExecution">
> > > > <xsd:complexType>
> > > > <xsd:sequence>
> > > > <xsd:element name="federationExecutionName"
> > > type="types:federationExecutionName"/>
> > > > <xsd:element name="fomDocumentDesignator"
> > > type="types:fomDocumentDesignator"/>
> > > > <xsd:element name="sessionID" type="types:sessionID"/>
> > > > </xsd:sequence>
> > > > </xsd:complexType>
> > > > </xsd:element>
> > > >
> > > > If I do like that I end up sending this on the wire, using the
> > stubs:
> > > >
> > >
> > <sessionID>-17</sessionID><sessionID>78</sessionID><sessionID>93</sessionID><sessionID>-37</sessionID>
> >
> > > (and so on)
> > > >
> > > > If I refer to base64Binary instead:
> > > > <xsd:element name="sessionID" type="xsd:base64Binary"/>
> > > > it works and I send this:
> > > > <sessionID xmlns="">705d28/1084c52a6e9//7ffe</sessionID>
> > > >
> > > > Any thoughts on this?
> > > >
> > > > regards,
> > > > Clarence
> > > >
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
>
>
Re: Bug in Axis 1.3, base64Binary?
Posted by Clarence Dahlin <cl...@gmail.com>.
Thank you Davanum.
So many other things got in between so I didn't try this until now. It
worked.
I thought I'd post this so anyone else having the same problem knows it
could solve their problem too.
kind regards,
Clarence
On 12/21/05, Davanum Srinivas <da...@gmail.com> wrote:
>
> did you try "ref" instead of "type"?
>
> On 12/21/05, Clarence Dahlin <cl...@gmail.com> wrote:
> > WSDL style is document/literal wrapped by the way.
> >
> >
> > On 12/21/05, Clarence Dahlin <clarence.pitch@gmail.com > wrote:
> > > I've come across a somewhat puzzling problem. Could this be a bug or
> what
> > am I doing wrong?
> > > I'm using Axis 1.3 final and generated the client stubs with the
> WSDL2Java
> > tool.
> > >
> > > I'm using a modular WSDL, like this:
> > >
> > > myWSDL.wsdl imports abstractwsdl.wsdl
> > > abstractwsdl.wsdl imports calls.xsd
> > > calls.xsd imports types.xsd
> > >
> > > I have a simple type in types.xsd as base64Binary:
> > > <xsd:simpleType name="sessionID">
> > > <xsd:restriction base="xsd:base64Binary"/>
> > > </xsd:simpleType>
> > >
> > > It is refered to in calls.xsd:
> > > <xsd:element name="createFederationExecution">
> > > <xsd:complexType>
> > > <xsd:sequence>
> > > <xsd:element name="federationExecutionName"
> > type="types:federationExecutionName"/>
> > > <xsd:element name="fomDocumentDesignator"
> > type="types:fomDocumentDesignator"/>
> > > <xsd:element name="sessionID" type="types:sessionID"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > </xsd:element>
> > >
> > > If I do like that I end up sending this on the wire, using the stubs:
> > >
> >
> <sessionID>-17</sessionID><sessionID>78</sessionID><sessionID>93</sessionID><sessionID>-37</sessionID>
> > (and so on)
> > >
> > > If I refer to base64Binary instead:
> > > <xsd:element name="sessionID" type="xsd:base64Binary"/>
> > > it works and I send this:
> > > <sessionID xmlns="">705d28/1084c52a6e9//7ffe</sessionID>
> > >
> > > Any thoughts on this?
> > >
> > > regards,
> > > Clarence
> > >
> >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
Re: Bug in Axis 1.3, base64Binary?
Posted by Davanum Srinivas <da...@gmail.com>.
did you try "ref" instead of "type"?
On 12/21/05, Clarence Dahlin <cl...@gmail.com> wrote:
> WSDL style is document/literal wrapped by the way.
>
>
> On 12/21/05, Clarence Dahlin <clarence.pitch@gmail.com > wrote:
> > I've come across a somewhat puzzling problem. Could this be a bug or what
> am I doing wrong?
> > I'm using Axis 1.3 final and generated the client stubs with the WSDL2Java
> tool.
> >
> > I'm using a modular WSDL, like this:
> >
> > myWSDL.wsdl imports abstractwsdl.wsdl
> > abstractwsdl.wsdl imports calls.xsd
> > calls.xsd imports types.xsd
> >
> > I have a simple type in types.xsd as base64Binary:
> > <xsd:simpleType name="sessionID">
> > <xsd:restriction base="xsd:base64Binary"/>
> > </xsd:simpleType>
> >
> > It is refered to in calls.xsd:
> > <xsd:element name="createFederationExecution">
> > <xsd:complexType>
> > <xsd:sequence>
> > <xsd:element name="federationExecutionName"
> type="types:federationExecutionName"/>
> > <xsd:element name="fomDocumentDesignator"
> type="types:fomDocumentDesignator"/>
> > <xsd:element name="sessionID" type="types:sessionID"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:element>
> >
> > If I do like that I end up sending this on the wire, using the stubs:
> >
> <sessionID>-17</sessionID><sessionID>78</sessionID><sessionID>93</sessionID><sessionID>-37</sessionID>
> (and so on)
> >
> > If I refer to base64Binary instead:
> > <xsd:element name="sessionID" type="xsd:base64Binary"/>
> > it works and I send this:
> > <sessionID xmlns="">705d28/1084c52a6e9//7ffe</sessionID>
> >
> > Any thoughts on this?
> >
> > regards,
> > Clarence
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Bug in Axis 1.3, base64Binary?
Posted by Clarence Dahlin <cl...@gmail.com>.
WSDL style is document/literal wrapped by the way.
On 12/21/05, Clarence Dahlin <cl...@gmail.com> wrote:
>
> I've come across a somewhat puzzling problem. Could this be a bug or what
> am I doing wrong?
> I'm using Axis 1.3 final and generated the client stubs with the WSDL2Java
> tool.
>
> I'm using a modular WSDL, like this:
>
> myWSDL.wsdl imports abstractwsdl.wsdl
> abstractwsdl.wsdl imports calls.xsd
> calls.xsd imports types.xsd
>
> I have a simple type in types.xsd as base64Binary:
> <xsd:simpleType name="sessionID">
> <xsd:restriction base="xsd:base64Binary"/>
> </xsd:simpleType>
>
> It is refered to in calls.xsd:
> <xsd:element name="createFederationExecution">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="federationExecutionName"
> type="types:federationExecutionName"/>
> <xsd:element name="fomDocumentDesignator"
> type="types:fomDocumentDesignator"/>
> <xsd:element name="sessionID" type="types:sessionID"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
> If I do like that I end up sending this on the wire, using the stubs:
> <sessionID>-17</sessionID><sessionID>78</sessionID><sessionID>93</sessionID><sessionID>-37</sessionID>
> (and so on)
>
> If I refer to base64Binary instead:
> <xsd:element name="sessionID" type="xsd:base64Binary"/>
> it works and I send this:
> <sessionID xmlns="">705d28/1084c52a6e9//7ffe</sessionID>
>
> Any thoughts on this?
>
> regards,
> Clarence
>