axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <atma...@gmail.com>
Subject Re: request always calls the first operation defined in server-config.wsdd
Date Fri, 11 Aug 2006 15:42:55 GMT
Each operation must have a unique signature, i.e., you must specify a
different qname for your two input parameters. (They can be the same
type, but they must have different names.)

Anne

On 8/11/06, Richard Jones <richard.d.jones@imperial.ac.uk> wrote:
> Hi Folks,
>
> I am starting to really get to grips with my web services now, with much
> thanks to Axis.  This morning, though, I have encountered a problem
> which I can't work out whether is my fault (likely) or a potential problem.
>
> I have two requests defined (in the scope of this problem):
>
> public void requestFileDetails(String guid)
>    throws ServiceException, RemoteException
> {
>    // make the request
>    SpiralTestSoapService service = getService();
>    SingleGUID sguid = new SingleGUID(guid);
>    RequestFileDetailsResponse response =
>      service.requestFileDetails(sguid);
> }
>
> public void articleUpdateNotification(String guid)
>    throws ServiceException, RemoteException
> {
>    // make the request
>    SpiralTestSoapService service = getService();
>    SingleGUID sguid = new SingleGUID(guid);
>    service.articleUpdateNotification(sguid);
> }
>
> these in turn call the relevant operations on the port type (The
> xxx_BindingImpl class).
>
> When either of the above methods are called in the client, the server
> /always/ processes the request to "requestFileDetails".  I discovered
> that I could fix this so that it always processed the request to
> "articleUpdateNotification" by reversing the order that these two
> operations are specified in the server-config.wsdd:
>
> <operation name="articleUpdateNotification"
>      qname="ArticleUpdateNotification" mep="oneway" >
>    <parameter qname="pns:SingleGUID"
>        xmlns:pns="http://[...]/SpiralWebService/" type="tns:>SingleGUID"
>        xmlns:tns="http://[...]/SpiralWebService/"/>
> </operation>
> <operation name="requestFileDetails" qname="RequestFileDetails"
>      returnQName="retNS:RequestFileDetailsResponse"
>      xmlns:retNS="http://[...]/SpiralWebService/"
>      returnType="rtns:>RequestFileDetailsResponse"
>      xmlns:rtns="http://[...]/SpiralWebService/" >
>    <parameter qname="pns:SingleGUID"
>        xmlns:pns="http://[...]/SpiralWebService/"
>        type="tns:>SingleGUID"
>        xmlns:tns="http://[...]/SpiralWebService/"/>
> </operation>
>
> I upped log4j to DEBUG, and observed that the body of the request seems
> only to contain the data type, not the operation name:
>
> 2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider
> @ body is <SingleGUID xmlns="http://[...]/SpiralWebService/"><guid
> xmlns="">1234567890</guid></SingleGUID>
>
> The two above methods both take the SingleGUID data type as an argument,
> so I defined this type in the WSDL and re-used it all over the place.
> My current guess (and it is only a guess) is that Axis is just looking
> for the first operation that takes this data type, and executing it, no
> matter which operation it was intended for.
>
> Can anyone see what I might have done wrong?  Am I misappropriating the
> data types and the way that axis uses them, or have I missed something
> in the way to call the web service, or is there something else?
>
> Any help much appreciated,
>
> Cheers
>
> --
> Richard
> -------
> Richard Jones
> Web and Database Technology Specialist
> Imperial College London
> t: +44 (0)20 759 41815
> e: richard.d.jones@imperial.ac.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message