[MOBY] Re: [MOBY-l] A Java web service problem

[Mark Wilkinson]

my messages are encoded as:

xsi:type = http://schemas.xmlsoap.org/soap/encoding/base64

your messages are encoded as:

xsi:type = http://www.w3.org/2001/XMLSchema/base64Binary

That is likely the source of the problem.

Interestingly, soap:base64 is defined as:

<xs:simpleType name="base64">
<xs:restriction base="xs:base64Binary"/>
</xs:simpleType>

So it shouldn't *really* make a difference.  I might jot a quick note to
Paul Kulchenko later today to ask him if this is a bug in SOAP Lite, or
if the payload really does have to be defined by a soap encoding
data-type rather than directly as an XML Schema data-type.

In the meantime, perhaps you should do as Martin suggests and switch
back to regular strings... interestingly, Viji's services pass their
output as 

xsi:type=http://www.w3.org/2001/XMLSchema/string

i.e. the SOAP Body data-type is defined by an XML schema, rather than a
SOAP encoding style, so it seems more and more like the problem we are
seeing is a bug in SOAP::Lite...

Michael, can you put your services back to the state they were in when
you were passing your data as string so that I can look at the output
again?

Thanks!

Mark


On Thu, 2004-03-04 at 03:34, Martin Senger wrote:
> As I understand you are using Mark's client to access your service. The
> client indicates "Service returned no response". But obviouly your service
> got iys request. If this is the case I would recommend:
> 
>    1) to look into your service code and trace step by step what it does
> with this particular request,
>    2) to try an independent client, perhaps one written in Java, to see if
> its behaviour is the same as the Mark's one,
> 
>    For this type of debugging it would be easier to go back (just for a 
> while) to type String - and use TCP monitor (provided by Axis) to see what 
> is really on the wire.
> 
>    Remember that I already suggested to you to give me the endpoint of 
> your service and I can test it from here by my clients (which is roughly 
> the same as ad 2) above).
> 
>    Martin
-- 
Mark Wilkinson (mwilkinson at mrl.ubc.ca)
University of British Columbia iCAPTURE Centre