Thanks Sam,
1) I'll change the echoTest deploy.wsdd to register the appropriate type
mappings for the arrays.
That should be done regardless.
2) I agree that sending the more specific type information is useful in the
overloaded method case.
So it may be more appropriate to serialize the specific type of the array.
If I have some time
I will run a test to see how many interop tests fail if we send the
specific array type.
3) Another question/comment :-). Previously axis only accepted arrays
with type="soapenc:Array", because
the specific array qnames were not registered. The type= information
provided no specific information about
the kind of array to instantiate. Thus the array deserializer is written
to always use the arrayType= attribute to figure
out the kind of array to instantiate. Clearly if we are going to
accept type="ns:ArrayOfFoo", the deserializer should use the
"ns:ArrayOfFoo" type to figure out the kind of
array to instantiate, and the runtime should not fail if arrayType= is
missing.
For example if "ns:Array" -->my. Base[] and "ns:Element" --> my.Derive
(assume Derive inherits from Base).
<name type="ns:Array" soapenc:arrayType="ns:Element[3]"> ....
Should be deserialized into an array of type my.Base[] with elements that
are my.Derive.
(Currently the array deserializer would create an array of my.Derive[].)
And if the following is specified:
<name type="ns:Array" soapenc:arrayType="xsd:anyType[3]"> ....
The deserializer deserialize into an array of type my.Base[] with
individual elements instantiated using the type= attributes of the
elements.
(I believe the current deserializer will either fail or build an Object[]
array.)
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Sam
Ruby/Raleigh/IBM@ To: [EMAIL PROTECTED]
IBMUS cc:
Subject: Re: AXIS/SOAP Interop Test
Summary
02/06/2002 09:54
AM
Please respond to
axis-dev
R J Scheuerle wrote:
>
> I have some questions...
>
> So a runtime could send an array using "style A":
>
> <name type="soapenc:Array" soapenc:arrayType="ns:foo[3]" >
>
> Or a runtime could send an array using "style B":
>
> <name type="ns:ArrayOfFoo" soapenc:arrayType="ns:foo[3]" >
>
> Apache SOAP is sending "style B"; I believe it used to send "style A".
> Apache Axis sends "style A".
Apache SOAP will simply send the last one that happens to be registered.
It used to be the case that only "style A" was registered. Now "style B"
has been added - at the end.
Instead of thinking of these two as styles, I have an analogy that you
might find helpful:
public class test {
public static void count(Object[] arg) {
System.out.println(arg.length);
}
public static void main(String args[]) {
count(new Object[] {"a", "b", "c"});
count(new String[] {"a", "b", "c"});
}
}
Note that the method named count accepts not only arrays of objects, but
also any subclasses of this type. ArrayOfFoo is more specific than Array.
------------------------------------------------------------------------------------------------
> A compliant runtime can receive an array of type "style A".
> In this case the deserializer is easily found because the type is
> "soapenc:Array".
It is not clear to me that a compliant runtime need accept arrays of type
"Style A", but in my opinion, they should. Be liberal in what you
accept...
> A compliant runtime can receive an array of type "style B".
> In this case, the runtime will attempt to find a deserializer of type
> "ns:ArrayOfFoo". In the case of Axis below, "ns:ArrayOfFoo" is not
> registered in the deploy.wsdd for samples.echo.TestClient.
>
> QUESTION 1: So should the behaviour be 1) fail as below or 2) if a
> deserializer is not found
> choose the array deserializer if the soapenc:arrayType attribute is
> present?
>
> My answer: I can make the change to implement (2) if I get some feedback
> from axis-dev.
I'd prefer (3) require that a specific deserializer be deployed for this
type. Modify the provide sample to demonstrate how this is done. That's
what was done in Apache SOAP.
In any case, I clearly don't care for option (1) above.
> QUESTION 2: Since the runtime can easily choose which style to send,
should
> we lean
> towards sending "style A" since it is more likely to be accepted by the
> remote runtime?
>
> My answer: We should send "style A"
I'm OK with that, but over time we may need to revisit this. My concern is
over things like operator overloading - when we get there we may need to
have the more specific information in order to correctly disambiguate the
choices.
- Sam Ruby
