Return-Path: 
 <axis-dev-return-18828-apmail-xml-axis-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org
Received: (qmail 90471 invoked by uid 500); 28 Jan 2003 21:57:13 -0000
Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
list-help: <mailto:axis-dev-help@xml.apache.org>
list-unsubscribe: <mailto:axis-dev-unsubscribe@xml.apache.org>
list-post: <mailto:axis-dev@xml.apache.org>
Delivered-To: mailing list axis-dev@xml.apache.org
Received: (qmail 90397 invoked from network); 28 Jan 2003 21:57:13 -0000
Message-ID: 
 <CB1FF0A474AEA84EA0206D5B05F6A4CB031D7F7B@S1001EXM02.macromedia.com>
From: Glen Daniels <gdaniels@macromedia.com>
To: "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
Subject: RE: Bug in RPCElement.java?
Date: Tue, 28 Jan 2003 16:57:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


Hi Tim!

Yup, I think this is a bug.

If the schema for the message indicates the "arrayness" of the "obj" parameter comes from a minOccurs/maxOccurs constraint rather than from SOAP encoding, then an array of one value might look like this:

   [example 1]
   <obj>insert myobject1 here</obj>

and a larger one like this:

   [example 2]
   <obj>insert myobject1 here</obj>
   <obj>insert myobject2 here</obj>

On the other hand, if it's SOAP encoded, it'll look like this:

   [example 3]
   <obj>
     <item>insert myobject1 here</item>
   </obj>

It's pretty easy to tell the difference between example 3 and example 1, and we should be doing at least that correctly.  In other words, if we're expecting a SOAP array and get a plain old value, we should NOT match on the array version even though isConvertible() says we can.  This part is relatively easy.

However, it's not so easy to tell the difference between a plain old value and an array containing a single plain old value when using maxOccurs="unbounded".  So if you're expecting something like example 2 above and get example 1, the only way we can fix it to prefer the single-value version over the array version is to change the scan in RPCElement to continue even after a "probable match" to find a better one.  This is doable as well, though.

Could you file this as a bugzilla bug?  Thanks!

--Glen

> -----Original Message-----
> From: Tim Dierks [mailto:timdnp@yahoo.com]
> Sent: Tuesday, January 28, 2003 4:05 PM
> To: axis-dev@xml.apache.org
> Subject: Bug in RPCElement.java?
> 
> 
> I am having a problem with Axis 1.1 Beta mapping a
> request to the proper method and it appears that the
> class RPCElement is choosing the wrong operation for
> my call.  I would like to know if anyone considers
> this a bug or not.
> 
> My web service contains overloaded methods.  For
> example, here are two methods:
> 
> 1) MyObject test1(String s1, String s2, MyObject obj);
> 
> 2) MyObject[] test1(String s1, String s2, MyObject[]
> obj);
> 
> When my client calls method (1), Axis executes method
> (2) on the server.  I ran my debugger with the Axis
> code and found that the class RPCElement selects the
> first matching operation that is a good fit rather
> than the one that is the exact fit.  This is because
> the method isConvertable() in JavaUtils says it is OK
> to map a single instance of a class to an array of the
> class.
> 
> If I shuffle methods (1) and (2) around in my web
> service's source code so that method (2) is found
> before (1), everything works OK.  In my real
> application, I have five versions of the overloaded
> method plus many other methods, so this example has
> been simplified.
> 
> This behavior seems to be a bug.  Shouldn't RPCElement
> be finding the EXACT match instead of the first one
> that might be suitable?  Can anyone comment on whether
> this is a bug or not?
> 
> Thanks,
> 
> Tim Dierks
> 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>