axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew J. Duftler" <duft...@watson.ibm.com>
Subject RE: cvs commit: xml-axis/java/src/org/apache/axis/utils/cache JavaMethod.java
Date Tue, 05 Jun 2001 21:07:47 GMT
>    2) One can produce better error messages if a near match is
> obtained and
>    verified against.  The best xml-soap could do was to say "method not
>    found".  In many cases, xml-axis can tell you what signature you were
>    attempting, what signature would work - even in some cases where an
>    argument of the wrong type is passed or an argument is missing
> entirely.

Actually Sam, that code was written by Joe Kesselman several years ago, and
for as long as I can remember has printed out the signature of the desired
method in all cases. Just tried this:

Ouch, the call failed:
  Fault Code   = SOAP-ENV:Server
  Fault String = Exception while handling service request:
samples.stockquote.StockQuoteService.getQuote(java.lang.String,int) -- no
signature match

Seems quite a bit more specific than "method not found".

>    found".  In many cases, xml-axis can tell you what signature you were
>    attempting, what signature would work - even in some cases where an

Are you saying that in some cases, xml-axis can't tell you what signature
you were attempting? Or are you saying it always does what xml-soap does,
and in some cases it can provide suggestions as to how to match an actual
signature?

Thanks,
-Matt

> -----Original Message-----
> From: Sam Ruby [mailto:rubys@us.ibm.com]
> Sent: Tuesday, June 05, 2001 6:06 AM
> To: axis-dev@xml.apache.org
> Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis/utils/cache
> JavaMethod.java
>
>
> Doug Davis:
> >
> > To say that we'll match on # of args but then never use the # of args
> > when the name is unique was wrong to me.  Granted a check for
> > null would be nice, but I still think it needs to check # of args
> > since the soap-env might have a different # of args than
> > the java method and this search will match on it -which is
> > wrong.
>
> Since you are telling me what you thing is wrong, let me return the favor.
> I realize that you are not accustomed to methods with comments in
> them, but
> to change the definintion of what a method does without updating the
> comments, introducing two bugs in the process, and changing the unit test
> for that function to stop detecting one of the bugs you introduced
> certainly seems wrong to me.
>
> I added a comment that "-1" should be used when "don't care" is desired.
> If you wish to complete this by only returning a different # of arguments
> if -1 is passed, feel free.  But before you do, here's some background on
> the the reasons why the current code is the way it is:
>
>    1) It generally is more efficient to do one look up than two.
>
>    2) One can produce better error messages if a near match is
> obtained and
>    verified against.  The best xml-soap could do was to say "method not
>    found".  In many cases, xml-axis can tell you what signature you were
>    attempting, what signature would work - even in some cases where an
>    argument of the wrong type is passed or an argument is missing
> entirely.
>
> I also presume that you would like to see the MessageContext parameter
> continue to work.  In order to help this, I added a unit test
> case for this
> function.  You might consider starting to do likewise.  Take a look at
> TestRPC.testMessageContext and Service.targetService.  It is not
> difficult...
>
> - Sam Ruby
>


Mime
View raw message