axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject Re: AXIS/SOAP Interop Test Summary
Date Wed, 06 Feb 2002 15:54:44 GMT
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) {

       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

> 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

- Sam Ruby

View raw message