Possible bug

[Lee Kamentsky <le...@navic.tv>]

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>> 

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>> 
>