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 <[EMAIL PROTECTED]> 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 >
