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 Mike Moran <mi...@mac.com> on 2005/04/14 17:14:22 UTC
Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Hi. I am currently moving over from a Java client api generated from
WSDL using JAX-RPC 1.4 to instead use Axis 1.2-RC3. I have existing code
which uses the JAX-RPC generated API so I was hoping that the JAX-RPC
binding 'standard' would make this fairly easy i.e I could regenerate
and compile against the same interface but with a different underlying
implementation.
However, I am finding that 'xsd:unsignedByte' is being bound to
'org.apache.axis.types.UnsignedByte' as opposed to 'short'. This then
leads to the arrays of this type also being unusable.
I notice that JAXB defaults 'xsd:unsignedByte' to be mapped to 'short'.
Is it possible to get Axis to do the same? Is this a bug in Axis or a
misunderstanding of a spec, or just a decision left open in a spec? Can
I override Axis's choice of what to map to?
Btw, I had a look at TypeMappingImpl; does dotnet_soapenc_bugfix have
anything to do with this? Note that I'm doing all this generation from
the wsdl2java ant task, so something I could set from there would be
nice (in an ideal world ;-) ).
FYO, an example of the input WSDL is:
<complexType name="Array4OfunsignedByte">
<complexContent>
<restriction base="SOAP-ENC:Array">
<attribute ref="SOAP-ENC:arrayType"
WSDL:arrayType="xsd:unsignedByte[]"/>
</restriction>
</complexContent>
</complexType>
This is using rpc/encoded btw, if that matters.
Thanks,
--
Mike
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Mike Moran <mi...@mac.com>.
Mike Moran wrote:
> Mike Moran wrote:
>
>> Anne Thomas Manes wrote:
>>
>>> Mike,
>>>
>>> Did you log a bug? I want to make sure this is fixed in Axis 1.2 Final.
[ ... ]
>
> This bug has now been added as
> http://issues.apache.org/jira/browse/AXIS-1930
It would seem this bug is 'fixed' by using typemapping=1.3. However,
this isn't documented (see bug comments). My attitude is that if it
isn't documented, then it doesn't exist, since how could I find it? How
do we go about making sure this gets properly fixed in the release?
Also, why isn't it the default?
--
Mike
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Mike Moran <mi...@mac.com>.
Mike Moran wrote:
> Anne Thomas Manes wrote:
>
>> Mike,
>>
>> Did you log a bug? I want to make sure this is fixed in Axis 1.2 Final.
>
>
> Hi. No, not yet, I'm just in the process of producing a small example
> test case.
This bug has now been added as
http://issues.apache.org/jira/browse/AXIS-1930
--
Mike
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Mike Moran <mi...@mac.com>.
Anne Thomas Manes wrote:
> Mike,
>
> Did you log a bug? I want to make sure this is fixed in Axis 1.2 Final.
Hi. No, not yet, I'm just in the process of producing a small example
test case.
--
Mike
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Anne Thomas Manes <at...@gmail.com>.
Mike,
Did you log a bug? I want to make sure this is fixed in Axis 1.2 Final.
Thanks,
Anne
On 4/15/05, Mike Moran <mi...@mac.com> wrote:
> Jeff Greif wrote:
> > I think there is a workaround which may enable a slightly tweaked client
> > to work on straight JAX-RPC and on Axis. You'd add a piece that looked
> > up the type mappings for the types that are treated different in the two
> > implementations, such as xsd:unsignedByte, xsd:anyURI and override the
> > Axis default type mappings to agree with those of JAX-RPC. I haven't
> > tried this exact thing, but I have done something similar, in mapping
> > anyURI to and from String rather than some Axis class.
> >
> > Something like this was needed in the deployment descriptor:
> > <typeMapping
> > deserializer="org.apache.axis.encoding.ser.SimpleDeserializerFactory"
> > serializer="org.apache.axis.encoding.ser.SimpleSerializerFactory"
> > languageSpecificType="java:java.lang.String"
> > encodingStyle=""
> > qname="xsd:anyURI"/>
> >
> > This mapping could be made in your client java code instead if you were
> > unwilling to have a different deployment descriptor for an axis-based
> > client from that of a pure jax-rpc client.
>
> So, I can use this method with the wsdl2java ant task to force a JAX-RPC
> compliant binding? I simply ask this because I've managed to get the
> classes generated without any usage of a deployment descriptor (wsdd?)
> so-far. Btw, I am RTFM, but there is so much of it and related SOAP
> stuff to read[1].
>
> [1]: http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research
>
> --
> Mike
>
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Mike Moran <mi...@mac.com>.
Jeff Greif wrote:
> I think there is a workaround which may enable a slightly tweaked client
> to work on straight JAX-RPC and on Axis. You'd add a piece that looked
> up the type mappings for the types that are treated different in the two
> implementations, such as xsd:unsignedByte, xsd:anyURI and override the
> Axis default type mappings to agree with those of JAX-RPC. I haven't
> tried this exact thing, but I have done something similar, in mapping
> anyURI to and from String rather than some Axis class.
>
> Something like this was needed in the deployment descriptor:
> <typeMapping
> deserializer="org.apache.axis.encoding.ser.SimpleDeserializerFactory"
> serializer="org.apache.axis.encoding.ser.SimpleSerializerFactory"
> languageSpecificType="java:java.lang.String"
> encodingStyle=""
> qname="xsd:anyURI"/>
>
> This mapping could be made in your client java code instead if you were
> unwilling to have a different deployment descriptor for an axis-based
> client from that of a pure jax-rpc client.
So, I can use this method with the wsdl2java ant task to force a JAX-RPC
compliant binding? I simply ask this because I've managed to get the
classes generated without any usage of a deployment descriptor (wsdd?)
so-far. Btw, I am RTFM, but there is so much of it and related SOAP
stuff to read[1].
[1]: http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research
--
Mike
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Jeff Greif <jg...@alumni.princeton.edu>.
I think there is a workaround which may enable a slightly tweaked client
to work on straight JAX-RPC and on Axis. You'd add a piece that looked
up the type mappings for the types that are treated different in the two
implementations, such as xsd:unsignedByte, xsd:anyURI and override the
Axis default type mappings to agree with those of JAX-RPC. I haven't
tried this exact thing, but I have done something similar, in mapping
anyURI to and from String rather than some Axis class.
Something like this was needed in the deployment descriptor:
<typeMapping
deserializer="org.apache.axis.encoding.ser.SimpleDeserializerFactory"
serializer="org.apache.axis.encoding.ser.SimpleSerializerFactory"
languageSpecificType="java:java.lang.String"
encodingStyle=""
qname="xsd:anyURI"/>
This mapping could be made in your client java code instead if you were
unwilling to have a different deployment descriptor for an axis-based
client from that of a pure jax-rpc client.
Jeff
Anne Thomas Manes wrote:
>JAX-RPC 1.1 also requires mapping of xsd:unsignedByte to short. (You
>would think that the TCK would test for this.) Since one of the goals
>of Axis 1.2 is to pass JAX-RPC 1.1 certification, this issue should be
>fixed for Axis 1.2 final.
>
>I suggest you log a bug report.
>
>Anne
>
>On 4/14/05, Mike Moran <mi...@mac.com> wrote:
>
>
>>Hi. I am currently moving over from a Java client api generated from
>>WSDL using JAX-RPC 1.4 to instead use Axis 1.2-RC3. I have existing code
>>which uses the JAX-RPC generated API so I was hoping that the JAX-RPC
>>binding 'standard' would make this fairly easy i.e I could regenerate
>>and compile against the same interface but with a different underlying
>>implementation.
>>
>>However, I am finding that 'xsd:unsignedByte' is being bound to
>>'org.apache.axis.types.UnsignedByte' as opposed to 'short'. This then
>>leads to the arrays of this type also being unusable.
>>
>>I notice that JAXB defaults 'xsd:unsignedByte' to be mapped to 'short'.
>>Is it possible to get Axis to do the same? Is this a bug in Axis or a
>>misunderstanding of a spec, or just a decision left open in a spec? Can
>>I override Axis's choice of what to map to?
>>
>>Btw, I had a look at TypeMappingImpl; does dotnet_soapenc_bugfix have
>>anything to do with this? Note that I'm doing all this generation from
>>the wsdl2java ant task, so something I could set from there would be
>>nice (in an ideal world ;-) ).
>>
>>FYO, an example of the input WSDL is:
>>
>><complexType name="Array4OfunsignedByte">
>> <complexContent>
>> <restriction base="SOAP-ENC:Array">
>> <attribute ref="SOAP-ENC:arrayType"
>>WSDL:arrayType="xsd:unsignedByte[]"/>
>> </restriction>
>> </complexContent>
>> </complexType>
>>
>>This is using rpc/encoded btw, if that matters.
>>
>>Thanks,
>>
>>--
>>Mike
>>
>>
>>
>
>
>
>
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Anne Thomas Manes <at...@gmail.com>.
JAX-RPC 1.1 also requires mapping of xsd:unsignedByte to short. (You
would think that the TCK would test for this.) Since one of the goals
of Axis 1.2 is to pass JAX-RPC 1.1 certification, this issue should be
fixed for Axis 1.2 final.
I suggest you log a bug report.
Anne
On 4/14/05, Mike Moran <mi...@mac.com> wrote:
> Hi. I am currently moving over from a Java client api generated from
> WSDL using JAX-RPC 1.4 to instead use Axis 1.2-RC3. I have existing code
> which uses the JAX-RPC generated API so I was hoping that the JAX-RPC
> binding 'standard' would make this fairly easy i.e I could regenerate
> and compile against the same interface but with a different underlying
> implementation.
>
> However, I am finding that 'xsd:unsignedByte' is being bound to
> 'org.apache.axis.types.UnsignedByte' as opposed to 'short'. This then
> leads to the arrays of this type also being unusable.
>
> I notice that JAXB defaults 'xsd:unsignedByte' to be mapped to 'short'.
> Is it possible to get Axis to do the same? Is this a bug in Axis or a
> misunderstanding of a spec, or just a decision left open in a spec? Can
> I override Axis's choice of what to map to?
>
> Btw, I had a look at TypeMappingImpl; does dotnet_soapenc_bugfix have
> anything to do with this? Note that I'm doing all this generation from
> the wsdl2java ant task, so something I could set from there would be
> nice (in an ideal world ;-) ).
>
> FYO, an example of the input WSDL is:
>
> <complexType name="Array4OfunsignedByte">
> <complexContent>
> <restriction base="SOAP-ENC:Array">
> <attribute ref="SOAP-ENC:arrayType"
> WSDL:arrayType="xsd:unsignedByte[]"/>
> </restriction>
> </complexContent>
> </complexType>
>
> This is using rpc/encoded btw, if that matters.
>
> Thanks,
>
> --
> Mike
>
Re: Wanting xsd:unsignedByte[] as short[] and not UnsignedByte[]
Posted by Mike Moran <mi...@mac.com>.
Mike Moran wrote:
> Hi. I am currently moving over from a Java client api generated from
> WSDL using JAX-RPC 1.4 to instead use Axis 1.2-RC3. I have existing code
> which uses the JAX-RPC generated API so I was hoping that the JAX-RPC
> binding 'standard' would make this fairly easy i.e I could regenerate
> and compile against the same interface but with a different underlying
> implementation.
Just replying to correct myself here because I meant Java Web Services
Developer Pack (JWSDP) version 1.4 (not JAX-RPC 1.4). Btw, JWSDP 1.4
seems to come with JAX-RPC version 1.1.2 (according to
jaxrpc/docs/ReleaseNotes.html).
> However, I am finding that 'xsd:unsignedByte' is being bound to
> 'org.apache.axis.types.UnsignedByte' as opposed to 'short'. This then
> leads to the arrays of this type also being unusable.
>
> I notice that JAXB defaults 'xsd:unsignedByte' to be mapped to 'short'.
> Is it possible to get Axis to do the same? Is this a bug in Axis or a
> misunderstanding of a spec, or just a decision left open in a spec? Can
> I override Axis's choice of what to map to?
>
> Btw, I had a look at TypeMappingImpl; does dotnet_soapenc_bugfix have
> anything to do with this? Note that I'm doing all this generation from
> the wsdl2java ant task, so something I could set from there would be
> nice (in an ideal world ;-) ).
>
> FYO, an example of the input WSDL is:
>
> <complexType name="Array4OfunsignedByte">
> <complexContent>
> <restriction base="SOAP-ENC:Array">
> <attribute ref="SOAP-ENC:arrayType"
> WSDL:arrayType="xsd:unsignedByte[]"/>
> </restriction>
> </complexContent>
> </complexType>
>
> This is using rpc/encoded btw, if that matters.
>
> Thanks,
>
--
Mike