Re: Possible bug [Axis]

[Josh Rehman <jr...@citysearch.com>]

Hi Lee,

I'm curious - how did you get a jws file with complex return values to 
deploy? Where did you put the dependant .class files?

Thanks so much,
Josh

Lee Kamentsky wrote:
> Dear all,
> Before launching into a minor complaint, let me say that I was thrilled by
> how easy it was to install Axis in Tomcat and create a web service. This
> enabled me to pitch SOAP in general and Axis in particular to my company.
> THANKS!
> 
> Anyway, I created a .jws file that returns an array of java bean objects. I
> modified the bean to return an array of byte as hexBinary instead of
> base64Binary (so that I could eyeball the field in the SOAP message). The
> bean correctly serializes and deserializes in hexBinary format, but the WSDL
> for the bean specifies that it should be sent as base64Binary.
> 
> Enclosed is TransmitData.wsdl, TransmitData.jws and Message.java. The
> Message.java fields, "macAddress" and "correlationID" both get the wrong
> translation. I believe the problem lies in
> org.apache.axis.encoding.ser.BeanSerializer on or around line # 385. There
> needs to be a case that checks for a non-null fieldXMLType and emits the
> overridden encoding.
> 
> ------
> 
> Also, for enhancement # 9815 (restrictions), if I could butt in, I agree
> with some commenters that the restrictions are best placed within the
> FieldDesc class (I'd allow generic restrictions rather than a fixed set). I
> would allow org.apache.axis.encoding.DeserializerTarget to have a nullable
> reference to the field descriptor and let it validate the restrictions
> inside its "set" method. If you need someone to hack this in, I'd be happy
> to provide a patch that did it (given enough lead time).
> 
> -- Lee
> 
>  <<Message.java>>  <<TransmitData.jws>>  <<TransmitData.wsdl>> 
>