axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: array test
Date Tue, 04 Dec 2001 16:06:40 GMT
I can't remember which solution is which anymore.  However,
if we fix it so that we follow the "href" when looking for the xsi:type
I believe my testcase would work.
-Dug


Sam Ruby/Raleigh/IBM@IBMUS on 12/04/2001 11:04:08 AM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: array test



Doug Davis wrote:
>
> Finally got a small testcase:
> (See attached file: array.zip)
> Run testClient1 and you'll see the error.

Lightbulb dimly flickering.

My first reaction when runing that test is OF COURSE IT FAILED!  It
references a data type which Axis has no knowledge of.  But seeing how all
of the preceeding discussion or test cases didn't seem to enlighten me, I
decided to dig further.

Two things I found:

(1) As Glen noted, Axis currently looks only as much as it has to.  Once it
finds an answer it likes it doesn't tend to look much futher.  Glen
proposes that we validate for constency other answers.

(2) The order of checking isn't consistent.  It appears that the xsi:type
on the argument is looked at first, then the registry is looked into, then
the xsi:type on referenced elements.

(3) I haven't checked, but it seems quite likely that we don't currently
have all of the logic in place to automatically understand the schema
information in the WSDL to the point where we would recognize a completely
defined ArrayOfFoo as an array of Foo.

 = = = =

If I understand this discussion correctly (big *if*, I know), if Glen were
to make all of the changes he is contemplating, then Doug's test case will
still fail in exactly the same way.

My feeling is that #3 is the most important as there will be cases where we
will want to interoperate without writing any code with services that we
have never seen before - perhaps within gateways or intermediaries.

If #1 is done, then I'm not sure I see the point to #2.

In fact, I'm not entirely comfortable with the suggestion that #2 be fixed
in a way that the xsi:type always wins, particularly in this scenario.
Suppose I call a service and declare that I expect an array of Foo back,
and what actually is received is an array of ints.  Should Axis provide
what it received, even if it did not match what was specified?  This would
mean that every call to axis clients would have to have code which checked
the results.  Or should this check be factored into Axis itself and a fault
be generated.

- Sam Ruby




Mime
View raw message