You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by keith chapman <ke...@gmail.com> on 2008/09/01 11:13:06 UTC
Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Hi Nick,
Sorry I couldn't get back to you sooner. Was held up with some travel
last week. So here goes, see my comments inline. (As a summary could
you try this with 1.4.1 as I did fix some REST bugs for this release)
On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
<ni...@imperial.ac.uk> wrote:
>
> Hi,
>
> I've recently started looking at using the REST support in Axis2 to invoke
> my web service instead of the currently used SOAP calls and I have a number
> of issues I can't work out for myself. Any help with these would be great.
> I've been using Axis2 version 1.3 (and then also tried 1.4 in the hope my
> issues would be solved) and tcpmon to monitor the traffic between my test
> client and my service running locally on tomcat at
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService. The
> WSDL is created using java2wsdl and is attached.
>
> I've read in another (old) post here that Axis2 is just a soap stack and any
> incoming rest style messages are converted into soap messages first so that
> they can then be processed. Is this still the case?
Yes. Axis2 is primarily a SOAP engine and hence once a message gets
into axis2 it has a SOAP message. So when Axis2 receives a REST
message we do create a SOAP message out of it.
Does this have a
> performance hit? Is there anything in the documentation about this?
>
>
> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
> client, to use the rest style web calls with the bindings is it simply a
> case of adding the line of code below into my client?
> options.setProperty(Constants.Configuration.ENABLE_REST,
> Constants.VALUE_TRUE);
> I want to clarify this since all the examples I have seen do not use
> bindings.
>
>
> Is it possible to use both POST and GET when my operation parameters are all
> simple types? To change between the two transports is it simply a case of
> options.setProperty(Constants.Configuration.HTTP_METHOD, HTTP_METHOD_GET);
> Or
> options.setProperty(Constants.Configuration.HTTP_METHOD, HTTP_METHOD_POST);
> ?
Yes you could set the HTTP Method you need as explained above. Axis2
also supports PUT and DELETE.
>
>
> I've found that I can use POST with operations that have parameters but not
> on those without parameters. For example, a call to getGigsIn("London")
> using HTTP_POST makes the following successful request:
> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> Content-Type: application/xml; charset=UTF-8
> SOAPAction: urn:getGigsIn
> User-Agent: Axis2
> Content-Length: 115
>
> <ns2:getGigsIn
> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>
> But a call to getMostActiveArtist() makes the following unsuccessful
> request:
> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> Content-Type: application/xml; charset=UTF-8
> SOAPAction: urn:getMostActiveArtist
> User-Agent: Axis2
> Content-Length: 0
>
> with received error:
> <faultstring>The endpoint reference (EPR) for the Operation not found is
> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
> null</faultstring>
>
> Why doesn't this work??
>
>
> After setting the HTTP_METHOD to HTTP_GET I am unable to make any successful
> calls to my service. getGigsIn("London") gives:
> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London HTTP/1.1
> Content-Type: application/x-www-form-urlencoded;
> charset=UTF-8;action="urn:getGigsIn";
> SOAPAction: urn:getGigsIn
> User-Agent: Axis2
>
> <soapenv:Reason
> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
> xml:lang="en-US">The endpoint reference (EPR) for the Operation not found is
> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
> null</soapenv:Text></soapenv:Reason>
>
> while getMostActiveArtist() gives:
> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> Content-Type: application/x-www-form-urlencoded;
> charset=UTF-8;action="urn:getMostActiveArtist";
> SOAPAction: urn:getMostActiveArtist
> User-Agent: Axis2
>
> And the same error response.
>
> Shouldn't the bindings be appending the operation name onto the end of the
> endpoint for me? If I explicitly set the endpoint to
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
> it makes the following request:
> GET /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
> HTTP/1.1
> Content-Type: application/x-www-form-urlencoded;
> charset=UTF-8;action="urn:getGigsIn";
> SOAPAction: urn:getGigsIn
> User-Agent: Axis2
>
> Which still gives an error, but this time:
> <soapenv:Reason
> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
> xml:lang="en-US">Exception occurred while trying to invoke service method
> getGigsIn</soapenv:Text></soapenv:Reason>
>
> If I simply go to
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
> in my browser I get the correct response.
The above should work for you correctly with codegenerated stubs. Can
you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
invocation for this release and verified that these stuff work.
>
> For me, one of the advantages of the generated bindings is not having to
> worry about the contents of the WSDL; I shouldn't have to know that the WSDL
> says I must specify the "city" parameter in my query string for the
> getGigsIn operation. Why are my ADB bindings setting "param0" instead?
This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
answer to this.
>
>
> Finally, the documentation specifies that Axis2 determines if an incoming
> message is REST or SOAP by checking if "the content type is text/xml and if
> the SOAPAction Header is missing". If you examine the requests the
> following headers are present for each method.
> HTTP_GET: Both SOAPAction and "action" in Content-Type
> HTTP_POST: Just SOAPAction
> SOAP: Just "action" in Content-Type
>
> What is going on here, are these the correct headers? And what is the
> "SOAPAction Header", is it "SOAPAction" or is it "action" in Content-Type!?
> I also found that when using POST I can even remove the SOAPAction header
> but providing I ensure the Content-Type still contains "application/xml" I
> will still receive the correct (non-soap) response from the service.
>
>
> I'm aware I might be doing something fundamentally wrong on the client side
> (maybe you can't use ADB bindings?) to get these results and I'd be very
> grateful for any responses to any of these questions.
You can use codegenerated stub to invoke REST services.
Thanks,
Keith.
>
> Thanks,
> Nick
> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
> --
> View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
RE: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Martin Gainty <mg...@hotmail.com>.
virtually impossible to tell without looking at the wsdl specifically
published operations
parameters for those operations
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Date: Tue, 2 Sep 2008 10:40:26 -0700
> From: nicholas.steel05@imperial.ac.uk
> To: axis-user@ws.apache.org
> Subject: Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
>
>
> I have now generated the httpbindings using wsdl2java with a version 2.0 wsdl
> and the operation has been added to the EPR as desired and I can do POST
> getGigsIn("London"), POST getMostActiveArtist() and GET
> getMostActiveArtist() without any problems which is great. The headers for
> both GET and POST are also now the same (see below) which makes a lot more
> sense to me.
> Content-Type: application/xml; charset=UTF-8
> SOAPAction: ""
>
>
> However, when I try to do GET getGigsIn("London") I get the error
> <faultstring>unknown</faultstring>. The request according to TCPmon is:
> GET
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
> HTTP/1.1
> Content-Type: application/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Axis2
> Host: 10.4.39.241:8089
>
> The operation is there in the URL but the parameter "London" is not so it's
> obviously not going to work. I was expecting something more like
> GET
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
> HTTP/1.1
>
> Whats going wrong here?
>
> Also, just to see what would happen, I tried to make some httpbindings using
> a version 1.1 wsdl but the generated stub had methods like void getGigsIn()
> and void getMostActiveArtist() which don't take or return any values so I
> couldn't work out how I could possibly use them. Is this normal or is this
> the reason you said to use a version 2.0 wsdl?
>
> Cheers,
> Nick
>
>
> keith chapman wrote:
> >
> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
> > <ni...@imperial.ac.uk> wrote:
> >>
> >> Keith,
> >>
> >> I had no idea ?wsdl2 even existed,
> >
> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
> > HTTPBinding can describe a REST interface for your service in a nice
> > manner.
> >
> > I've no idea how I managed to miss this
> >> but I will hunt for it tomorrow and give it a go. Thanks very much this
> >> reply, what you say aout the EPR has definitely cleared some things up
> >> for
> >> me and hopefully I can now go on to get this to work.
> >>
> >> Just to be clear though, you say I should generate the client stub for
> >> the
> >> httpbinding, how exactly do I do this? I thought the stub I already had
> >> could handle all the bindings in my wsdl and that setting the portal
> >> parameters was what controlled which binding was being used. Is this
> >> wrong?
> >
> > When codegeneration is used to generate the server side code its only
> > the portType (or the interface if WSDL 2.0) that we care about when
> > generating code. But when its generating code for the client side we
> > generate it for a particular port and you can specify this by using
> > the -pn option. If a port if not provided it faults to use the first
> > SOAP 1.2 port it finds. You could generate code for all ports too this
> > can be done by using the -ap options. This will generate stubs for all
> > ports in the WSDL. So for example if I take the same RESTSample that I
> > used yesterday this is how I would generate code for its HTTPBinding.
> >
> > wsdl2java.sh -uri http://mooshup.com/services/samples/RESTSample?wsdl2
> > -pn HTTPEndpoint -wv 2
> >
> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
> >
> > Thanks,
> > Keith.
> >>
> >> Cheers,
> >> Nick
> >>
> >>
> >> keith chapman wrote:
> >>>
> >>> Hi Nick,
> >>>
> >>> If you want to invoke a service using REST then its better to generate
> >>> the client stub for the httpBinding (and when doing so I recommend you
> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
> >>> interface of the service. This is where it will contain details of the
> >>> URL the operation is available at hence if this binding is used to
> >>> invoke the service it will automatically add the operation name to the
> >>> end of the EPR. This does not happen for the SOAP bindings though.
> >>> This is the reason for the behavior you observed below.
> >>>
> >>> In the request you have sent below does not contain enough information
> >>> to dispatch it to the correct operation of the service. If you had the
> >>> operation name at the end of it it would have worked. And BTW when you
> >>> are using service client directly it will not append the operation
> >>> name to the EPR. Note that you have to configure the ServiceClient
> >>> your self when using this. (This is not the case for stubs generated
> >>> for the httpBinding though).
> >>>
> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
> >>> <ni...@imperial.ac.uk> wrote:
> >>>>
> >>>> Thank you Jay and Keith for your replies. I've upgraded to version
> >>>> 1.4.1
> >>>> but
> >>>> this had made no difference. Below is a really simple version of my
> >>>> code
> >>>> taking the options used by Jay in his working service but I can still
> >>>> only
> >>>> get the correct response using getGigsIn() with POST, every other
> >>>> combination else fails with:
> >>>> <soapenv:Reason
> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for
> >>>> the
> >>>> Operation not found is /NicksGigs-war-Axis2/services/GigListingsService
> >>>> and
> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
> >>>>
> >>>> SimpleREST.java:
> >>>> String epr =
> >>>> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
> >>>> Options options = portal._getServiceClient().getOptions();
> >>>> options.setProperty(Constants.Configuration.ENABLE_REST, Boolean.TRUE);
> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >>>> Constants.Configuration.HTTP_METHOD_POST);
> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
> >>>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
> >>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
> >>>> Constants.VALUE_TRUE);
> >>>> options.setCallTransportCleanup(true);
> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
> >>>> portal._getServiceClient().setOptions(options);
> >>>> Gig[] results = portal.getGigsIn("London");
> >>>> for (int j = 0; j < results.length; j++)
> >>>> System.out.println(results[j].getToString());
> >>>>
> >>>> Note that I had to comment out the MESSAGE_TYPE property for this to
> >>>> work. I
> >>>> have also commented out the SOAP_ACTION property here since although it
> >>>> did
> >>>> remove the action(s) in the header it didn't make any difference to the
> >>>> end
> >>>> result.
> >>>>
> >>>> The thing which strikes me most about this is that whether using GET or
> >>>> POST
> >>>> the bindings do not append the method names to the endpoint like I
> >>>> would
> >>>> expect them to. I wrongly assumed that at some point the axis
> >>>> generated
> >>>> code would do something like endpoint+"/"+methodName but it doesn't
> >>>> seem
> >>>> to... Is this correct behaviour?
> >>>>
> >>>> I took a look at the blog entry and after a closer look at my WSDL it
> >>>> seems
> >>>> that the one generated at
> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the correct
> >>>> parameter names, but the wsdl generated by the maven java2wsdl plugin
> >>>> and
> >>>> then subsequently used by wsdl2java to create my stub has the param0,
> >>>> param1
> >>>> names. Maven automatically compiles with debug on and I've made no
> >>>> changes
> >>>> to this so I am a bit confused why I'm getting this. Even more so by
> >>>> the
> >>>> fact that if I create unwrapped bindings then the correct parameter
> >>>> names
> >>>> are used.
> >>>
> >>> This is strange. I haven't tried this out though (wsdl2java maven
> >>> plugin). Would give it a try and let you know.
> >>>
> >>> Thanks,
> >>> Keith.
> >>>>
> >>>> Thanks
> >>>> Nick
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> keith chapman wrote:
> >>>>>
> >>>>> Hi Nick,
> >>>>>
> >>>>> Sorry I couldn't get back to you sooner. Was held up with some travel
> >>>>> last week. So here goes, see my comments inline. (As a summary could
> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this release)
> >>>>>
> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
> >>>>> <ni...@imperial.ac.uk> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've recently started looking at using the REST support in Axis2 to
> >>>>>> invoke
> >>>>>> my web service instead of the currently used SOAP calls and I have a
> >>>>>> number
> >>>>>> of issues I can't work out for myself. Any help with these would be
> >>>>>> great.
> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the
> >>>>>> hope
> >>>>>> my
> >>>>>> issues would be solved) and tcpmon to monitor the traffic between my
> >>>>>> test
> >>>>>> client and my service running locally on tomcat at
> >
> >>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
> >>>>>> The
> >>>>>> WSDL is created using java2wsdl and is attached.
> >>>>>>
> >>>>>> I've read in another (old) post here that Axis2 is just a soap stack
> >>>>>> and
> >>>>>> any
> >>>>>> incoming rest style messages are converted into soap messages first
> >>>>>> so
> >>>>>> that
> >>>>>> they can then be processed. Is this still the case?
> >>>>>
> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
> >>>>> message we do create a SOAP message out of it.
> >>>>>
> >>>>> Does this have a
> >>>>>> performance hit? Is there anything in the documentation about this?
> >>>>>>
> >>>>>>
> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
> >>>>>> client, to use the rest style web calls with the bindings is it
> >>>>>> simply
> >>>>>> a
> >>>>>> case of adding the line of code below into my client?
> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> >>>>>> Constants.VALUE_TRUE);
> >>>>>> I want to clarify this since all the examples I have seen do not use
> >>>>>> bindings.
> >>>>>>
> >>>>>>
> >>>>>> Is it possible to use both POST and GET when my operation parameters
> >>>>>> are
> >>>>>> all
> >>>>>> simple types? To change between the two transports is it simply a
> >>>>>> case
> >>>>>> of
> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >>>>>> HTTP_METHOD_GET);
> >>>>>> Or
> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >>>>>> HTTP_METHOD_POST);
> >>>>>> ?
> >>>>>
> >>>>> Yes you could set the HTTP Method you need as explained above. Axis2
> >>>>> also supports PUT and DELETE.
> >>>>>>
> >>>>>>
> >>>>>> I've found that I can use POST with operations that have parameters
> >>>>>> but
> >>>>>> not
> >>>>>> on those without parameters. For example, a call to
> >>>>>> getGigsIn("London")
> >>>>>> using HTTP_POST makes the following successful request:
> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >>>>>> Content-Type: application/xml; charset=UTF-8
> >>>>>> SOAPAction: urn:getGigsIn
> >>>>>> User-Agent: Axis2
> >>>>>> Content-Length: 115
> >>>>>>
> >>>>>> <ns2:getGigsIn
> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
> >>>>>>
> >>>>>> But a call to getMostActiveArtist() makes the following unsuccessful
> >>>>>> request:
> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >>>>>> Content-Type: application/xml; charset=UTF-8
> >>>>>> SOAPAction: urn:getMostActiveArtist
> >>>>>> User-Agent: Axis2
> >>>>>> Content-Length: 0
> >>>>>>
> >>>>>> with received error:
> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation not found
> >>>>>> is
> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
> >>>>>> null</faultstring>
> >>>>>>
> >>>>>> Why doesn't this work??
> >>>>>>
> >>>>>>
> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
> >>>>>> successful
> >>>>>> calls to my service. getGigsIn("London") gives:
> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
> >>>>>> HTTP/1.1
> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >>>>>> SOAPAction: urn:getGigsIn
> >>>>>> User-Agent: Axis2
> >>>>>>
> >>>>>> <soapenv:Reason
> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not
> >>>>>> found
> >>>>>> is
> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
> >>>>>> null</soapenv:Text></soapenv:Reason>
> >>>>>>
> >>>>>> while getMostActiveArtist() gives:
> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
> >>>>>> SOAPAction: urn:getMostActiveArtist
> >>>>>> User-Agent: Axis2
> >>>>>>
> >>>>>> And the same error response.
> >>>>>>
> >>>>>> Shouldn't the bindings be appending the operation name onto the end
> >>>>>> of
> >>>>>> the
> >>>>>> endpoint for me? If I explicitly set the endpoint to
> >>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
> >>>>>> it makes the following request:
> >>>>>> GET
> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
> >>>>>> HTTP/1.1
> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >>>>>> SOAPAction: urn:getGigsIn
> >>>>>> User-Agent: Axis2
> >>>>>>
> >>>>>> Which still gives an error, but this time:
> >>>>>> <soapenv:Reason
> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke service
> >>>>>> method
> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
> >>>>>>
> >>>>>> If I simply go to
> >>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
> >>>>>> in my browser I get the correct response.
> >>>>>
> >>>>> The above should work for you correctly with codegenerated stubs. Can
> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
> >>>>> invocation for this release and verified that these stuff work.
> >>>>>>
> >>>>>> For me, one of the advantages of the generated bindings is not having
> >>>>>> to
> >>>>>> worry about the contents of the WSDL; I shouldn't have to know that
> >>>>>> the
> >>>>>> WSDL
> >>>>>> says I must specify the "city" parameter in my query string for the
> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
> >>>>>> instead?
> >>>>>
> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
> >>>>> answer to this.
> >>>>>>
> >>>>>>
> >>>>>> Finally, the documentation specifies that Axis2 determines if an
> >>>>>> incoming
> >>>>>> message is REST or SOAP by checking if "the content type is text/xml
> >>>>>> and
> >>>>>> if
> >>>>>> the SOAPAction Header is missing". If you examine the requests the
> >>>>>> following headers are present for each method.
> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
> >>>>>> HTTP_POST: Just SOAPAction
> >>>>>> SOAP: Just "action" in Content-Type
> >>>>>>
> >>>>>> What is going on here, are these the correct headers? And what is the
> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
> >>>>>> Content-Type!?
> >>>>>> I also found that when using POST I can even remove the SOAPAction
> >>>>>> header
> >>>>>> but providing I ensure the Content-Type still contains
> >>>>>> "application/xml"
> >>>>>> I
> >>>>>> will still receive the correct (non-soap) response from the service.
> >>>>>>
> >>>>>>
> >>>>>> I'm aware I might be doing something fundamentally wrong on the
> >>>>>> client
> >>>>>> side
> >>>>>> (maybe you can't use ADB bindings?) to get these results and I'd be
> >>>>>> very
> >>>>>> grateful for any responses to any of these questions.
> >>>>>
> >>>>> You can use codegenerated stub to invoke REST services.
> >>>>>
> >>>>> Thanks,
> >>>>> Keith.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Nick
> >>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Keith Chapman
> >>>>> Senior Software Engineer
> >>>>> WSO2 Inc.
> >>>>> Oxygenating the Web Service Platform.
> >>>>> http://wso2.org/
> >>>>>
> >>>>> blog: http://www.keith-chapman.org
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Keith Chapman
> >>> Senior Software Engineer
> >>> WSO2 Inc.
> >>> Oxygenating the Web Service Platform.
> >>> http://wso2.org/
> >>>
> >>> blog: http://www.keith-chapman.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Keith Chapman
> > Senior Software Engineer
> > WSO2 Inc.
> > Oxygenating the Web Service Platform.
> > http://wso2.org/
> >
> > blog: http://www.keith-chapman.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
_________________________________________________________________
Be the filmmaker you always wanted to be—learn how to burn a DVD with Windows®.
http://clk.atdmt.com/MRT/go/108588797/direct/01/
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
Great OK that is all clear now. I'd just like to correct my code I posted
before since I set the CONTENT_TYPE property instead of the MESSAGE_TYPE
property and the former doesn't work as required (in fact I don't know what
it actually does since they both set the Content-Type header but only
MESSAGE-TYPE appends the parameters).
My (very nearly completely) working REST code is
String epr =
"http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
NicksGigsServiceV2Stub portal = new NicksGigsServiceV2Stub(epr);
Options options = portal._getServiceClient().getOptions();
// GET
options.setProperty(Constants.Configuration.HTTP_METHOD,
Constants.Configuration.HTTP_METHOD_GET);
options.setProperty(Constants.Configuration.MESSAGE_TYPE,"application/x-www-form-urlencoded");
portal.getMostActiveArtist();
portal.getGigsIn("London"); // Only this operation now fails due to wrong
param name in querystring
// POST
options.setProperty(Constants.Configuration.HTTP_METHOD,
Constants.Configuration.HTTP_METHOD_POST);
options.setProperty(Constants.Configuration.MESSAGE_TYPE,"application/xml");
portal.getMostActiveArtist();
portal.getGigsIn("London");
I would not have worked any of this out for myself and it might be good to
put something about using wsdl version 2.0 and httpbindings when using
databindings in the documentation for other newbies to find. There is a bit
more to using REST and changing between GET and POST than people might first
expect.
Many thanks,
Nick
keith chapman wrote:
>
> Hi Nick,
>
> See my comments inline
>
> On Wed, Sep 3, 2008 at 6:38 PM, Nick Steel
> <ni...@imperial.ac.uk>wrote:
>
>>
>> Thanks for your speedy reply Keith. I have been using the following code
>> to
>> test today:
>> String epr =
>> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>> portal = new NicksGigsServiceV2Stub(epr);
>> Options options = portal._getServiceClient().getOptions();
>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> Constants.Configuration.HTTP_METHOD_GET);
>>
>> int countResults = getGigsIn("London").length;
>> System.out.println("Found " + countResults + " results.");
>>
>> After having another look at the generated stub I can see that POST,
>> application/XML and a load of other properties are hard coded in each
>> method.
>
>
> The stub is generated off the WSDL and the WSDL states which httpMethod
> and
> which content-type an operation is exposed under. Hence when the stub is
> generated these details are hard coded into the stub.
>
>
>> I had originally assumed that axis would have changed the
>> CONTENT_TYPE to the correct one for my chosen HTTP_METHOD further down
>> the
>> line before sending, but (I'm guessing) this doesn't happen in order to
>> remain flexible.
>>
>
> Yes, This is how the message formatting logic works. We check weather the
> MESSAGE_TYPE property is set and if it is set we use that as the
> content-type. If we fail to find the above property we use defaulting
> rules
> and the default for a GET is application/x-www-form-urlencoded. So if you
> wanna change the method you better change the MESSAGE_TYPE too.
>
>
>>
>> I just tried adding
>>
>> options.setProperty(Constants.Configuration.CONTENT_TYPE,"application/x-www-form-urlencoded");
>> to my code which now appends the parameter (great!) but I'm back to one
>> of
>> my original problems in that it's using "param0" instead of "city" in the
>> query string. The request is below.
>> GET
>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>> HTTP/1.1
>> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
>> SOAPAction: ""
>> User-Agent: Axis2
>> Host: localhost:8089
>>
>> As you can see from my previously attached wsdls (which are generated
>> using
>> Maven java2wsdl) the getGigsIn element has one parameter called "param0"
>> so
>> it wouldn't be surprising to find the stub using this parameter name.
>> However, the wsdl generated at runtime by visiting
>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl (
>>
>> http://www.nabble.com/file/p19288850/GigListingsService-generated_at_runtime.wsdl
>> GigListingsService-generated_at_runtime.wsdl<http://www.nabble.com/file/p19288850/GigListingsService-generated_at_runtime.wsdlGigListingsService-generated_at_runtime.wsdl>)
>> correctly describes the
>> parameter as being called "city". As far as I can tell debug is enabled
>> by
>> default when using Maven
>> (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html)
>> but perhaps it is using a different source to wsdl generated at runtime?
>> The source class being used is an interface, could this be a problem?
>>
>
> Strange. I'll try to have a look into this issue tomorrow.
>
>>
>>
>> Since my wsdl is generated by Maven, and then client stubs from that to
>> do
>> testing, during build the idea of having to manually modify the wsdl to
>> change operations to GET/PUT whatever is a little awkward. Is it
>> possible
>> to annotate the Java service class interface used by java2wsdl so that it
>> can automatically detect which http method is needed for an operation?
>
>
> This is on my todo list. Expose WSDL2 properties as annotations and
> services.xml parameters. If time permits will work on it in the coming
> weeks
> (Definitely before the next release ;))
>
>>
>>
>> I didn't have any experience with web services before I started using
>> Axis2
>> a couple of months ago so maybe I am missing something here but it would
>> be
>> handy if in the stubs there was a way to easily change between GET, POST,
>> PUT and DELETE. This would then set all the properties you needed for it
>> to
>> work. Would this be something possible in the future?
>
>
> I just answered this question above. Well if you wanna change the http
> method you better change the content-type too. As of now the only way I've
> seen GET and DELETE requests formatted is using
> application/x-www-form-urlencoded. But who knows somebody might format in
> another way using some strange content-type...
>
> Thanks,
> Keith.
>
>>
>>
>> Nick
>>
>>
>> keith chapman wrote:
>> >
>> > Hi Nick,
>> >
>> > Looking through the WSDLs I don't see any reason for the input/output
>> > types
>> > in the stub to go missing when generated off a WSDL 1.1 doc. I may have
>> to
>> > test this to make sure that this is the case though. On the subject of
>> a
>> > particular operation not working when invoked via GET. In a previous
>> mail
>> > you said that " I have now generated the httpbindings using wsdl2java
>> with
>> > a
>> > version 2.0 wsdl and the operation has been added to the EPR as desired
>> > and
>> > I can do POST getGigsIn("London"), POST getMostActiveArtist() and GET
>> > getMostActiveArtist() without any problems which is great. "
>> >
>> > How did you send a GET to getMostActiveArtist()? I assume that you set
>> the
>> > httpmethod on the options object of the serviceClient to GET (cause the
>> > stub
>> > will send a POST by default according to the WSDL). Could you please
>> > explain
>> > a bit what you did to send that request. I just had a look at the code
>> and
>> > when its a GET or a DELETE we use the application/x-www-form-urlencoded
>> as
>> > the content-type. (BTW which version of axis2 did u use?)
>> >
>> > The default WSDL generated by axis2 will have all operations exposed
>> over
>> > POST with the inputSerialization of application/XML. If you need to
>> change
>> > this (expose some operations over GET) you may do so by hand editing
>> the
>> > generated WSDL and using that. This may be better cause you choose
>> which
>> > method you want to expose your operations under.
>> >
>> > Thanks,
>> > Keith.
>> >
>> > On Wed, Sep 3, 2008 at 2:28 PM, Nick Steel
>> > <ni...@imperial.ac.uk>wrote:
>> >
>> >>
>> >> Keith,
>> >>
>> >> Please find both versions of my wsdl attached. Note that these are
>> the
>> >> files generated using Maven java2wsdl at buildtime that I then go on
>> to
>> >> use
>> >> with Maven wsdl2java to get my client stubs.
>> >> http://www.nabble.com/file/p19285397/NicksGigs.wsdl NicksGigs.wsdl
>> >> http://www.nabble.com/file/p19285397/NicksGigsV2.wsdl NicksGigsV2.wsdl
>> >>
>> >> Ad you can see my wsdl doesn't contain any inputSerialization fields
>> at
>> >> all.
>> >> And the method seems to be POST be default, is this the problem?
>> >>
>> >> Nick
>> >>
>> >>
>> >> keith chapman wrote:
>> >> >
>> >> > Hi Nick,
>> >> >
>> >> > See My comments inline
>> >> >
>> >> > On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel
>> >> > <nicholas.steel05@imperial.ac.uk
>> >> >> wrote:
>> >> >
>> >> >>
>> >> >> I have now generated the httpbindings using wsdl2java with a
>> version
>> >> 2.0
>> >> >> wsdl
>> >> >> and the operation has been added to the EPR as desired and I can do
>> >> POST
>> >> >> getGigsIn("London"), POST getMostActiveArtist() and GET
>> >> >> getMostActiveArtist() without any problems which is great.
>> >> >
>> >> >
>> >> > Cool, thats good news.
>> >> >
>> >> >
>> >> >> The headers for
>> >> >> both GET and POST are also now the same (see below) which makes a
>> lot
>> >> >> more
>> >> >> sense to me.
>> >> >> Content-Type: application/xml; charset=UTF-8
>> >> >> SOAPAction: ""
>> >> >>
>> >> >
>> >> > I've already opened a JIRA against axis2 for the above. The client
>> >> should
>> >> > not sent the SOAP action when it is a REST request. Will fix this
>> soon
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> However, when I try to do GET getGigsIn("London") I get the error
>> >> >> <faultstring>unknown</faultstring>. The request according to
>> TCPmon
>> >> is:
>> >> >> GET
>> >> >>
>> >> >>
>> >>
>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
>> >> >> HTTP/1.1
>> >> >> Content-Type: application/xml; charset=UTF-8
>> >> >> SOAPAction: ""
>> >> >> User-Agent: Axis2
>> >> >> Host: 10.4.39.241:8089
>> >> >
>> >> >
>> >> > Something is obviously wrong here. You cannot send a GET using
>> >> > application/xml. A get should always be
>> >> application/x-www-form-urlencoded.
>> >> > Can yu check your WSDL2 section for this operation please. Does it
>> say
>> >> > what
>> >> > its inputSerialization is?
>> >> >
>> >> >
>> >> >> <http://10.4.39.241:8089>
>> >> >>
>> >> >> The operation is there in the URL but the parameter "London" is not
>> so
>> >> >> it's
>> >> >> obviously not going to work. I was expecting something more like
>> >> >> GET
>> >> >>
>> >> >>
>> >>
>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
>> >> >> HTTP/1.1
>> >> >>
>> >> >> Whats going wrong here?
>> >> >
>> >> >
>> >> > Just answered above ;).
>> >> >
>> >> >>
>> >> >>
>> >> >> Also, just to see what would happen, I tried to make some
>> httpbindings
>> >> >> using
>> >> >> a version 1.1 wsdl but the generated stub had methods like void
>> >> >> getGigsIn()
>> >> >> and void getMostActiveArtist() which don't take or return any
>> values
>> >> so
>> >> I
>> >> >> couldn't work out how I could possibly use them. Is this normal or
>> is
>> >> >> this
>> >> >> the reason you said to use a version 2.0 wsdl?httpBinding.
>> >> >>
>> >> >
>> >> > WSDL 2.0 has a much richer That is the reason I recommended you to
>> use
>> >> > that.
>> >> > But ?wsdl should have worked as well, we map the properties of ?wsdl
>> to
>> >> > the
>> >> > ones of ?wsdl2 during code generation. Is it possible for you to
>> share
>> >> > your
>> >> > wsdl and wsdl2 as well.
>> >> >
>> >> > Thanks,
>> >> > Keith.
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> Cheers,
>> >> >> Nick
>> >> >>
>> >> >>
>> >> >> keith chapman wrote:
>> >> >> >
>> >> >> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
>> >> >> > <ni...@imperial.ac.uk> wrote:
>> >> >> >>
>> >> >> >> Keith,
>> >> >> >>
>> >> >> >> I had no idea ?wsdl2 even existed,
>> >> >> >
>> >> >> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
>> >> >> > HTTPBinding can describe a REST interface for your service in a
>> nice
>> >> >> > manner.
>> >> >> >
>> >> >> > I've no idea how I managed to miss this
>> >> >> >> but I will hunt for it tomorrow and give it a go. Thanks very
>> much
>> >> >> this
>> >> >> >> reply, what you say aout the EPR has definitely cleared some
>> things
>> >> up
>> >> >> >> for
>> >> >> >> me and hopefully I can now go on to get this to work.
>> >> >> >>
>> >> >> >> Just to be clear though, you say I should generate the client
>> stub
>> >> for
>> >> >> >> the
>> >> >> >> httpbinding, how exactly do I do this? I thought the stub I
>> already
>> >> >> had
>> >> >> >> could handle all the bindings in my wsdl and that setting the
>> >> portal
>> >> >> >> parameters was what controlled which binding was being used. Is
>> >> this
>> >> >> >> wrong?
>> >> >> >
>> >> >> > When codegeneration is used to generate the server side code its
>> >> only
>> >> >> > the portType (or the interface if WSDL 2.0) that we care about
>> when
>> >> >> > generating code. But when its generating code for the client side
>> we
>> >> >> > generate it for a particular port and you can specify this by
>> using
>> >> >> > the -pn option. If a port if not provided it faults to use the
>> first
>> >> >> > SOAP 1.2 port it finds. You could generate code for all ports too
>> >> this
>> >> >> > can be done by using the -ap options. This will generate stubs
>> for
>> >> all
>> >> >> > ports in the WSDL. So for example if I take the same RESTSample
>> that
>> >> I
>> >> >> > used yesterday this is how I would generate code for its
>> >> HTTPBinding.
>> >> >> >
>> >> >> > wsdl2java.sh -uri
>> >> http://mooshup.com/services/samples/RESTSample?wsdl2
>> >> >> > -pn HTTPEndpoint -wv 2
>> >> >> >
>> >> >> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Keith.
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >> Nick
>> >> >> >>
>> >> >> >>
>> >> >> >> keith chapman wrote:
>> >> >> >>>
>> >> >> >>> Hi Nick,
>> >> >> >>>
>> >> >> >>> If you want to invoke a service using REST then its better to
>> >> >> generate
>> >> >> >>> the client stub for the httpBinding (and when doing so I
>> recommend
>> >> >> you
>> >> >> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the
>> REST
>> >> >> >>> interface of the service. This is where it will contain details
>> of
>> >> >> the
>> >> >> >>> URL the operation is available at hence if this binding is used
>> to
>> >> >> >>> invoke the service it will automatically add the operation name
>> to
>> >> >> the
>> >> >> >>> end of the EPR. This does not happen for the SOAP bindings
>> though.
>> >> >> >>> This is the reason for the behavior you observed below.
>> >> >> >>>
>> >> >> >>> In the request you have sent below does not contain enough
>> >> >> information
>> >> >> >>> to dispatch it to the correct operation of the service. If you
>> had
>> >> >> the
>> >> >> >>> operation name at the end of it it would have worked. And BTW
>> when
>> >> >> you
>> >> >> >>> are using service client directly it will not append the
>> operation
>> >> >> >>> name to the EPR. Note that you have to configure the
>> ServiceClient
>> >> >> >>> your self when using this. (This is not the case for stubs
>> >> generated
>> >> >> >>> for the httpBinding though).
>> >> >> >>>
>> >> >> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
>> >> >> >>> <ni...@imperial.ac.uk> wrote:
>> >> >> >>>>
>> >> >> >>>> Thank you Jay and Keith for your replies. I've upgraded to
>> >> version
>> >> >> >>>> 1.4.1
>> >> >> >>>> but
>> >> >> >>>> this had made no difference. Below is a really simple version
>> of
>> >> my
>> >> >> >>>> code
>> >> >> >>>> taking the options used by Jay in his working service but I
>> can
>> >> >> still
>> >> >> >>>> only
>> >> >> >>>> get the correct response using getGigsIn() with POST, every
>> other
>> >> >> >>>> combination else fails with:
>> >> >> >>>> <soapenv:Reason
>> >> >> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>> >> >> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference
>> >> (EPR)
>> >> >> for
>> >> >> >>>> the
>> >> >> >>>> Operation not found is
>> >> >> /NicksGigs-war-Axis2/services/GigListingsService
>> >> >> >>>> and
>> >> >> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>> >> >> >>>>
>> >> >> >>>> SimpleREST.java:
>> >> >> >>>> String epr =
>> >> >> >>>> "
>> >> >>
>> >>
>> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>> >> >> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>> >> >> >>>> Options options = portal._getServiceClient().getOptions();
>> >> >> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> >> >> Boolean.TRUE);
>> >> >> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >> >> >>>> Constants.Configuration.HTTP_METHOD_POST);
>> >> >> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>> >> >> >>>>
>> >> >>
>> >>
>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>> >> >> >>>>
>> >> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>> >> >> >>>> Constants.VALUE_TRUE);
>> >> >> >>>> options.setCallTransportCleanup(true);
>> >> >> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>> >> >> >>>> portal._getServiceClient().setOptions(options);
>> >> >> >>>> Gig[] results = portal.getGigsIn("London");
>> >> >> >>>> for (int j = 0; j < results.length; j++)
>> >> >> >>>> System.out.println(results[j].getToString());
>> >> >> >>>>
>> >> >> >>>> Note that I had to comment out the MESSAGE_TYPE property for
>> this
>> >> to
>> >> >> >>>> work. I
>> >> >> >>>> have also commented out the SOAP_ACTION property here since
>> >> although
>> >> >> it
>> >> >> >>>> did
>> >> >> >>>> remove the action(s) in the header it didn't make any
>> difference
>> >> to
>> >> >> the
>> >> >> >>>> end
>> >> >> >>>> result.
>> >> >> >>>>
>> >> >> >>>> The thing which strikes me most about this is that whether
>> using
>> >> GET
>> >> >> or
>> >> >> >>>> POST
>> >> >> >>>> the bindings do not append the method names to the endpoint
>> like
>> >> I
>> >> >> >>>> would
>> >> >> >>>> expect them to. I wrongly assumed that at some point the axis
>> >> >> >>>> generated
>> >> >> >>>> code would do something like endpoint+"/"+methodName but it
>> >> doesn't
>> >> >> >>>> seem
>> >> >> >>>> to... Is this correct behaviour?
>> >> >> >>>>
>> >> >> >>>> I took a look at the blog entry and after a closer look at my
>> >> WSDL
>> >> >> it
>> >> >> >>>> seems
>> >> >> >>>> that the one generated at
>> >> >> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has
>> the
>> >> >> correct
>> >> >> >>>> parameter names, but the wsdl generated by the maven java2wsdl
>> >> >> plugin
>> >> >> >>>> and
>> >> >> >>>> then subsequently used by wsdl2java to create my stub has the
>> >> >> param0,
>> >> >> >>>> param1
>> >> >> >>>> names. Maven automatically compiles with debug on and I've
>> made
>> >> no
>> >> >> >>>> changes
>> >> >> >>>> to this so I am a bit confused why I'm getting this. Even more
>> so
>> >> by
>> >> >> >>>> the
>> >> >> >>>> fact that if I create unwrapped bindings then the correct
>> >> parameter
>> >> >> >>>> names
>> >> >> >>>> are used.
>> >> >> >>>
>> >> >> >>> This is strange. I haven't tried this out though (wsdl2java
>> maven
>> >> >> >>> plugin). Would give it a try and let you know.
>> >> >> >>>
>> >> >> >>> Thanks,
>> >> >> >>> Keith.
>> >> >> >>>>
>> >> >> >>>> Thanks
>> >> >> >>>> Nick
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> keith chapman wrote:
>> >> >> >>>>>
>> >> >> >>>>> Hi Nick,
>> >> >> >>>>>
>> >> >> >>>>> Sorry I couldn't get back to you sooner. Was held up with
>> some
>> >> >> travel
>> >> >> >>>>> last week. So here goes, see my comments inline. (As a
>> summary
>> >> >> could
>> >> >> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this
>> >> >> release)
>> >> >> >>>>>
>> >> >> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>> >> >> >>>>> <ni...@imperial.ac.uk> wrote:
>> >> >> >>>>>>
>> >> >> >>>>>> Hi,
>> >> >> >>>>>>
>> >> >> >>>>>> I've recently started looking at using the REST support in
>> >> Axis2
>> >> >> to
>> >> >> >>>>>> invoke
>> >> >> >>>>>> my web service instead of the currently used SOAP calls and
>> I
>> >> have
>> >> >> a
>> >> >> >>>>>> number
>> >> >> >>>>>> of issues I can't work out for myself. Any help with these
>> >> would
>> >> >> be
>> >> >> >>>>>> great.
>> >> >> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4
>> in
>> >> the
>> >> >> >>>>>> hope
>> >> >> >>>>>> my
>> >> >> >>>>>> issues would be solved) and tcpmon to monitor the traffic
>> >> between
>> >> >> my
>> >> >> >>>>>> test
>> >> >> >>>>>> client and my service running locally on tomcat at
>> >> >> >
>> >> >> >>>>>>
>> >> >>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>> >> >> >>>>>> The
>> >> >> >>>>>> WSDL is created using java2wsdl and is attached.
>> >> >> >>>>>>
>> >> >> >>>>>> I've read in another (old) post here that Axis2 is just a
>> soap
>> >> >> stack
>> >> >> >>>>>> and
>> >> >> >>>>>> any
>> >> >> >>>>>> incoming rest style messages are converted into soap
>> messages
>> >> >> first
>> >> >> >>>>>> so
>> >> >> >>>>>> that
>> >> >> >>>>>> they can then be processed. Is this still the case?
>> >> >> >>>>>
>> >> >> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a
>> message
>> >> gets
>> >> >> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a
>> REST
>> >> >> >>>>> message we do create a SOAP message out of it.
>> >> >> >>>>>
>> >> >> >>>>> Does this have a
>> >> >> >>>>>> performance hit? Is there anything in the documentation
>> about
>> >> >> this?
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java
>> for
>> >> my
>> >> >> test
>> >> >> >>>>>> client, to use the rest style web calls with the bindings is
>> it
>> >> >> >>>>>> simply
>> >> >> >>>>>> a
>> >> >> >>>>>> case of adding the line of code below into my client?
>> >> >> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> >> >> >>>>>> Constants.VALUE_TRUE);
>> >> >> >>>>>> I want to clarify this since all the examples I have seen do
>> >> not
>> >> >> use
>> >> >> >>>>>> bindings.
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> Is it possible to use both POST and GET when my operation
>> >> >> parameters
>> >> >> >>>>>> are
>> >> >> >>>>>> all
>> >> >> >>>>>> simple types? To change between the two transports is it
>> >> simply
>> >> a
>> >> >> >>>>>> case
>> >> >> >>>>>> of
>> >> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >> >> >>>>>> HTTP_METHOD_GET);
>> >> >> >>>>>> Or
>> >> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >> >> >>>>>> HTTP_METHOD_POST);
>> >> >> >>>>>> ?
>> >> >> >>>>>
>> >> >> >>>>> Yes you could set the HTTP Method you need as explained
>> above.
>> >> >> Axis2
>> >> >> >>>>> also supports PUT and DELETE.
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> I've found that I can use POST with operations that have
>> >> >> parameters
>> >> >> >>>>>> but
>> >> >> >>>>>> not
>> >> >> >>>>>> on those without parameters. For example, a call to
>> >> >> >>>>>> getGigsIn("London")
>> >> >> >>>>>> using HTTP_POST makes the following successful request:
>> >> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService
>> HTTP/1.1
>> >> >> >>>>>> Content-Type: application/xml; charset=UTF-8
>> >> >> >>>>>> SOAPAction: urn:getGigsIn
>> >> >> >>>>>> User-Agent: Axis2
>> >> >> >>>>>> Content-Length: 115
>> >> >> >>>>>>
>> >> >> >>>>>> <ns2:getGigsIn
>> >> >> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
>> >> >> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>> >> >> >>>>>>
>> >> >> >>>>>> But a call to getMostActiveArtist() makes the following
>> >> >> unsuccessful
>> >> >> >>>>>> request:
>> >> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService
>> HTTP/1.1
>> >> >> >>>>>> Content-Type: application/xml; charset=UTF-8
>> >> >> >>>>>> SOAPAction: urn:getMostActiveArtist
>> >> >> >>>>>> User-Agent: Axis2
>> >> >> >>>>>> Content-Length: 0
>> >> >> >>>>>>
>> >> >> >>>>>> with received error:
>> >> >> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation
>> not
>> >> >> found
>> >> >> >>>>>> is
>> >> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>> >> >> Action
>> >> >> =
>> >> >> >>>>>> null</faultstring>
>> >> >> >>>>>>
>> >> >> >>>>>> Why doesn't this work??
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to
>> make
>> >> any
>> >> >> >>>>>> successful
>> >> >> >>>>>> calls to my service. getGigsIn("London") gives:
>> >> >> >>>>>> GET
>> >> /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>> >> >> >>>>>> HTTP/1.1
>> >> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>> >> >> >>>>>> SOAPAction: urn:getGigsIn
>> >> >> >>>>>> User-Agent: Axis2
>> >> >> >>>>>>
>> >> >> >>>>>> <soapenv:Reason
>> >> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>> >> >> "><soapenv:Text
>> >> >> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the
>> Operation
>> >> >> not
>> >> >> >>>>>> found
>> >> >> >>>>>> is
>> >> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>> >> >> Action
>> >> >> =
>> >> >> >>>>>> null</soapenv:Text></soapenv:Reason>
>> >> >> >>>>>>
>> >> >> >>>>>> while getMostActiveArtist() gives:
>> >> >> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService
>> HTTP/1.1
>> >> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >> >> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>> >> >> >>>>>> SOAPAction: urn:getMostActiveArtist
>> >> >> >>>>>> User-Agent: Axis2
>> >> >> >>>>>>
>> >> >> >>>>>> And the same error response.
>> >> >> >>>>>>
>> >> >> >>>>>> Shouldn't the bindings be appending the operation name onto
>> the
>> >> >> end
>> >> >> >>>>>> of
>> >> >> >>>>>> the
>> >> >> >>>>>> endpoint for me? If I explicitly set the endpoint to
>> >> >> >>>>>>
>> >> >>
>> >>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>> >> >> >>>>>> it makes the following request:
>> >> >> >>>>>> GET
>> >> >> >>>>>>
>> >> >>
>> >>
>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>> >> >> >>>>>> HTTP/1.1
>> >> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>> >> >> >>>>>> SOAPAction: urn:getGigsIn
>> >> >> >>>>>> User-Agent: Axis2
>> >> >> >>>>>>
>> >> >> >>>>>> Which still gives an error, but this time:
>> >> >> >>>>>> <soapenv:Reason
>> >> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>> >> >> "><soapenv:Text
>> >> >> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke
>> >> service
>> >> >> >>>>>> method
>> >> >> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>> >> >> >>>>>>
>> >> >> >>>>>> If I simply go to
>> >> >> >>>>>>
>> >> >>
>> >>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>> >> >> >>>>>> in my browser I get the correct response.
>> >> >> >>>>>
>> >> >> >>>>> The above should work for you correctly with codegenerated
>> >> stubs.
>> >> >> Can
>> >> >> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on
>> REST
>> >> >> >>>>> invocation for this release and verified that these stuff
>> work.
>> >> >> >>>>>>
>> >> >> >>>>>> For me, one of the advantages of the generated bindings is
>> not
>> >> >> having
>> >> >> >>>>>> to
>> >> >> >>>>>> worry about the contents of the WSDL; I shouldn't have to
>> know
>> >> >> that
>> >> >> >>>>>> the
>> >> >> >>>>>> WSDL
>> >> >> >>>>>> says I must specify the "city" parameter in my query string
>> for
>> >> >> the
>> >> >> >>>>>> getGigsIn operation. Why are my ADB bindings setting
>> "param0"
>> >> >> >>>>>> instead?
>> >> >> >>>>>
>> >> >> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you
>> >> the
>> >> >> >>>>> answer to this.
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> Finally, the documentation specifies that Axis2 determines
>> if
>> >> an
>> >> >> >>>>>> incoming
>> >> >> >>>>>> message is REST or SOAP by checking if "the content type is
>> >> >> text/xml
>> >> >> >>>>>> and
>> >> >> >>>>>> if
>> >> >> >>>>>> the SOAPAction Header is missing". If you examine the
>> requests
>> >> >> the
>> >> >> >>>>>> following headers are present for each method.
>> >> >> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>> >> >> >>>>>> HTTP_POST: Just SOAPAction
>> >> >> >>>>>> SOAP: Just "action" in Content-Type
>> >> >> >>>>>>
>> >> >> >>>>>> What is going on here, are these the correct headers? And
>> what
>> >> is
>> >> >> the
>> >> >> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>> >> >> >>>>>> Content-Type!?
>> >> >> >>>>>> I also found that when using POST I can even remove the
>> >> SOAPAction
>> >> >> >>>>>> header
>> >> >> >>>>>> but providing I ensure the Content-Type still contains
>> >> >> >>>>>> "application/xml"
>> >> >> >>>>>> I
>> >> >> >>>>>> will still receive the correct (non-soap) response from the
>> >> >> service.
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> I'm aware I might be doing something fundamentally wrong on
>> the
>> >> >> >>>>>> client
>> >> >> >>>>>> side
>> >> >> >>>>>> (maybe you can't use ADB bindings?) to get these results and
>> >> I'd
>> >> >> be
>> >> >> >>>>>> very
>> >> >> >>>>>> grateful for any responses to any of these questions.
>> >> >> >>>>>
>> >> >> >>>>> You can use codegenerated stub to invoke REST services.
>> >> >> >>>>>
>> >> >> >>>>> Thanks,
>> >> >> >>>>> Keith.
>> >> >> >>>>>>
>> >> >> >>>>>> Thanks,
>> >> >> >>>>>> Nick
>> >> >> >>>>>>
>> http://www.nabble.com/file/p19087933/example.wsdlexample.wsdl
>> >> >> >>>>>> --
>> >> >> >>>>>> View this message in context:
>> >> >> >>>>>>
>> >> >>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>> >> >> >>>>>> Sent from the Axis - User mailing list archive at
>> Nabble.com.
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> >>>>>> For additional commands, e-mail:
>> axis-user-help@ws.apache.org
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> Keith Chapman
>> >> >> >>>>> Senior Software Engineer
>> >> >> >>>>> WSO2 Inc.
>> >> >> >>>>> Oxygenating the Web Service Platform.
>> >> >> >>>>> http://wso2.org/
>> >> >> >>>>>
>> >> >> >>>>> blog: http://www.keith-chapman.org
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>> --
>> >> >> >>>> View this message in context:
>> >> >> >>>>
>> >> >>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>> >> >> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Keith Chapman
>> >> >> >>> Senior Software Engineer
>> >> >> >>> WSO2 Inc.
>> >> >> >>> Oxygenating the Web Service Platform.
>> >> >> >>> http://wso2.org/
>> >> >> >>>
>> >> >> >>> blog: http://www.keith-chapman.org
>> >> >> >>>
>> >> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
>> >> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Keith Chapman
>> >> >> > Senior Software Engineer
>> >> >> > WSO2 Inc.
>> >> >> > Oxygenating the Web Service Platform.
>> >> >> > http://wso2.org/
>> >> >> >
>> >> >> > blog: http://www.keith-chapman.org
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
>> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Keith Chapman
>> >> > Senior Software Engineer
>> >> > WSO2 Inc.
>> >> > Oxygenating the Web Service Platform.
>> >> > http://wso2.org/
>> >> >
>> >> > blog: http://www.keith-chapman.org
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19285397.html
>> >> Sent from the Axis - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Keith Chapman
>> > Senior Software Engineer
>> > WSO2 Inc.
>> > Oxygenating the Web Service Platform.
>> > http://wso2.org/
>> >
>> > blog: http://www.keith-chapman.org
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19288850.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19292231.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Posted by keith chapman <ke...@gmail.com>.
Hi Nick,
See my comments inline
On Wed, Sep 3, 2008 at 6:38 PM, Nick Steel
<ni...@imperial.ac.uk>wrote:
>
> Thanks for your speedy reply Keith. I have been using the following code
> to
> test today:
> String epr =
> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
> portal = new NicksGigsServiceV2Stub(epr);
> Options options = portal._getServiceClient().getOptions();
> options.setProperty(Constants.Configuration.HTTP_METHOD,
> Constants.Configuration.HTTP_METHOD_GET);
>
> int countResults = getGigsIn("London").length;
> System.out.println("Found " + countResults + " results.");
>
> After having another look at the generated stub I can see that POST,
> application/XML and a load of other properties are hard coded in each
> method.
The stub is generated off the WSDL and the WSDL states which httpMethod and
which content-type an operation is exposed under. Hence when the stub is
generated these details are hard coded into the stub.
> I had originally assumed that axis would have changed the
> CONTENT_TYPE to the correct one for my chosen HTTP_METHOD further down the
> line before sending, but (I'm guessing) this doesn't happen in order to
> remain flexible.
>
Yes, This is how the message formatting logic works. We check weather the
MESSAGE_TYPE property is set and if it is set we use that as the
content-type. If we fail to find the above property we use defaulting rules
and the default for a GET is application/x-www-form-urlencoded. So if you
wanna change the method you better change the MESSAGE_TYPE too.
>
> I just tried adding
>
> options.setProperty(Constants.Configuration.CONTENT_TYPE,"application/x-www-form-urlencoded");
> to my code which now appends the parameter (great!) but I'm back to one of
> my original problems in that it's using "param0" instead of "city" in the
> query string. The request is below.
> GET
> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
> HTTP/1.1
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> SOAPAction: ""
> User-Agent: Axis2
> Host: localhost:8089
>
> As you can see from my previously attached wsdls (which are generated using
> Maven java2wsdl) the getGigsIn element has one parameter called "param0" so
> it wouldn't be surprising to find the stub using this parameter name.
> However, the wsdl generated at runtime by visiting
> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl (
>
> http://www.nabble.com/file/p19288850/GigListingsService-generated_at_runtime.wsdl
> GigListingsService-generated_at_runtime.wsdl<http://www.nabble.com/file/p19288850/GigListingsService-generated_at_runtime.wsdlGigListingsService-generated_at_runtime.wsdl>) correctly describes the
> parameter as being called "city". As far as I can tell debug is enabled by
> default when using Maven
> (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html)
> but perhaps it is using a different source to wsdl generated at runtime?
> The source class being used is an interface, could this be a problem?
>
Strange. I'll try to have a look into this issue tomorrow.
>
>
> Since my wsdl is generated by Maven, and then client stubs from that to do
> testing, during build the idea of having to manually modify the wsdl to
> change operations to GET/PUT whatever is a little awkward. Is it possible
> to annotate the Java service class interface used by java2wsdl so that it
> can automatically detect which http method is needed for an operation?
This is on my todo list. Expose WSDL2 properties as annotations and
services.xml parameters. If time permits will work on it in the coming weeks
(Definitely before the next release ;))
>
>
> I didn't have any experience with web services before I started using Axis2
> a couple of months ago so maybe I am missing something here but it would be
> handy if in the stubs there was a way to easily change between GET, POST,
> PUT and DELETE. This would then set all the properties you needed for it
> to
> work. Would this be something possible in the future?
I just answered this question above. Well if you wanna change the http
method you better change the content-type too. As of now the only way I've
seen GET and DELETE requests formatted is using
application/x-www-form-urlencoded. But who knows somebody might format in
another way using some strange content-type...
Thanks,
Keith.
>
>
> Nick
>
>
> keith chapman wrote:
> >
> > Hi Nick,
> >
> > Looking through the WSDLs I don't see any reason for the input/output
> > types
> > in the stub to go missing when generated off a WSDL 1.1 doc. I may have
> to
> > test this to make sure that this is the case though. On the subject of a
> > particular operation not working when invoked via GET. In a previous mail
> > you said that " I have now generated the httpbindings using wsdl2java
> with
> > a
> > version 2.0 wsdl and the operation has been added to the EPR as desired
> > and
> > I can do POST getGigsIn("London"), POST getMostActiveArtist() and GET
> > getMostActiveArtist() without any problems which is great. "
> >
> > How did you send a GET to getMostActiveArtist()? I assume that you set
> the
> > httpmethod on the options object of the serviceClient to GET (cause the
> > stub
> > will send a POST by default according to the WSDL). Could you please
> > explain
> > a bit what you did to send that request. I just had a look at the code
> and
> > when its a GET or a DELETE we use the application/x-www-form-urlencoded
> as
> > the content-type. (BTW which version of axis2 did u use?)
> >
> > The default WSDL generated by axis2 will have all operations exposed over
> > POST with the inputSerialization of application/XML. If you need to
> change
> > this (expose some operations over GET) you may do so by hand editing the
> > generated WSDL and using that. This may be better cause you choose which
> > method you want to expose your operations under.
> >
> > Thanks,
> > Keith.
> >
> > On Wed, Sep 3, 2008 at 2:28 PM, Nick Steel
> > <ni...@imperial.ac.uk>wrote:
> >
> >>
> >> Keith,
> >>
> >> Please find both versions of my wsdl attached. Note that these are the
> >> files generated using Maven java2wsdl at buildtime that I then go on to
> >> use
> >> with Maven wsdl2java to get my client stubs.
> >> http://www.nabble.com/file/p19285397/NicksGigs.wsdl NicksGigs.wsdl
> >> http://www.nabble.com/file/p19285397/NicksGigsV2.wsdl NicksGigsV2.wsdl
> >>
> >> Ad you can see my wsdl doesn't contain any inputSerialization fields at
> >> all.
> >> And the method seems to be POST be default, is this the problem?
> >>
> >> Nick
> >>
> >>
> >> keith chapman wrote:
> >> >
> >> > Hi Nick,
> >> >
> >> > See My comments inline
> >> >
> >> > On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel
> >> > <nicholas.steel05@imperial.ac.uk
> >> >> wrote:
> >> >
> >> >>
> >> >> I have now generated the httpbindings using wsdl2java with a version
> >> 2.0
> >> >> wsdl
> >> >> and the operation has been added to the EPR as desired and I can do
> >> POST
> >> >> getGigsIn("London"), POST getMostActiveArtist() and GET
> >> >> getMostActiveArtist() without any problems which is great.
> >> >
> >> >
> >> > Cool, thats good news.
> >> >
> >> >
> >> >> The headers for
> >> >> both GET and POST are also now the same (see below) which makes a lot
> >> >> more
> >> >> sense to me.
> >> >> Content-Type: application/xml; charset=UTF-8
> >> >> SOAPAction: ""
> >> >>
> >> >
> >> > I've already opened a JIRA against axis2 for the above. The client
> >> should
> >> > not sent the SOAP action when it is a REST request. Will fix this soon
> >> >
> >> >
> >> >>
> >> >>
> >> >>
> >> >> However, when I try to do GET getGigsIn("London") I get the error
> >> >> <faultstring>unknown</faultstring>. The request according to TCPmon
> >> is:
> >> >> GET
> >> >>
> >> >>
> >>
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
> >> >> HTTP/1.1
> >> >> Content-Type: application/xml; charset=UTF-8
> >> >> SOAPAction: ""
> >> >> User-Agent: Axis2
> >> >> Host: 10.4.39.241:8089
> >> >
> >> >
> >> > Something is obviously wrong here. You cannot send a GET using
> >> > application/xml. A get should always be
> >> application/x-www-form-urlencoded.
> >> > Can yu check your WSDL2 section for this operation please. Does it say
> >> > what
> >> > its inputSerialization is?
> >> >
> >> >
> >> >> <http://10.4.39.241:8089>
> >> >>
> >> >> The operation is there in the URL but the parameter "London" is not
> so
> >> >> it's
> >> >> obviously not going to work. I was expecting something more like
> >> >> GET
> >> >>
> >> >>
> >>
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
> >> >> HTTP/1.1
> >> >>
> >> >> Whats going wrong here?
> >> >
> >> >
> >> > Just answered above ;).
> >> >
> >> >>
> >> >>
> >> >> Also, just to see what would happen, I tried to make some
> httpbindings
> >> >> using
> >> >> a version 1.1 wsdl but the generated stub had methods like void
> >> >> getGigsIn()
> >> >> and void getMostActiveArtist() which don't take or return any values
> >> so
> >> I
> >> >> couldn't work out how I could possibly use them. Is this normal or
> is
> >> >> this
> >> >> the reason you said to use a version 2.0 wsdl?httpBinding.
> >> >>
> >> >
> >> > WSDL 2.0 has a much richer That is the reason I recommended you to use
> >> > that.
> >> > But ?wsdl should have worked as well, we map the properties of ?wsdl
> to
> >> > the
> >> > ones of ?wsdl2 during code generation. Is it possible for you to share
> >> > your
> >> > wsdl and wsdl2 as well.
> >> >
> >> > Thanks,
> >> > Keith.
> >> >
> >> >
> >> >>
> >> >>
> >> >> Cheers,
> >> >> Nick
> >> >>
> >> >>
> >> >> keith chapman wrote:
> >> >> >
> >> >> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
> >> >> > <ni...@imperial.ac.uk> wrote:
> >> >> >>
> >> >> >> Keith,
> >> >> >>
> >> >> >> I had no idea ?wsdl2 even existed,
> >> >> >
> >> >> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
> >> >> > HTTPBinding can describe a REST interface for your service in a
> nice
> >> >> > manner.
> >> >> >
> >> >> > I've no idea how I managed to miss this
> >> >> >> but I will hunt for it tomorrow and give it a go. Thanks very
> much
> >> >> this
> >> >> >> reply, what you say aout the EPR has definitely cleared some
> things
> >> up
> >> >> >> for
> >> >> >> me and hopefully I can now go on to get this to work.
> >> >> >>
> >> >> >> Just to be clear though, you say I should generate the client stub
> >> for
> >> >> >> the
> >> >> >> httpbinding, how exactly do I do this? I thought the stub I
> already
> >> >> had
> >> >> >> could handle all the bindings in my wsdl and that setting the
> >> portal
> >> >> >> parameters was what controlled which binding was being used. Is
> >> this
> >> >> >> wrong?
> >> >> >
> >> >> > When codegeneration is used to generate the server side code its
> >> only
> >> >> > the portType (or the interface if WSDL 2.0) that we care about when
> >> >> > generating code. But when its generating code for the client side
> we
> >> >> > generate it for a particular port and you can specify this by using
> >> >> > the -pn option. If a port if not provided it faults to use the
> first
> >> >> > SOAP 1.2 port it finds. You could generate code for all ports too
> >> this
> >> >> > can be done by using the -ap options. This will generate stubs for
> >> all
> >> >> > ports in the WSDL. So for example if I take the same RESTSample
> that
> >> I
> >> >> > used yesterday this is how I would generate code for its
> >> HTTPBinding.
> >> >> >
> >> >> > wsdl2java.sh -uri
> >> http://mooshup.com/services/samples/RESTSample?wsdl2
> >> >> > -pn HTTPEndpoint -wv 2
> >> >> >
> >> >> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
> >> >> >
> >> >> > Thanks,
> >> >> > Keith.
> >> >> >>
> >> >> >> Cheers,
> >> >> >> Nick
> >> >> >>
> >> >> >>
> >> >> >> keith chapman wrote:
> >> >> >>>
> >> >> >>> Hi Nick,
> >> >> >>>
> >> >> >>> If you want to invoke a service using REST then its better to
> >> >> generate
> >> >> >>> the client stub for the httpBinding (and when doing so I
> recommend
> >> >> you
> >> >> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
> >> >> >>> interface of the service. This is where it will contain details
> of
> >> >> the
> >> >> >>> URL the operation is available at hence if this binding is used
> to
> >> >> >>> invoke the service it will automatically add the operation name
> to
> >> >> the
> >> >> >>> end of the EPR. This does not happen for the SOAP bindings
> though.
> >> >> >>> This is the reason for the behavior you observed below.
> >> >> >>>
> >> >> >>> In the request you have sent below does not contain enough
> >> >> information
> >> >> >>> to dispatch it to the correct operation of the service. If you
> had
> >> >> the
> >> >> >>> operation name at the end of it it would have worked. And BTW
> when
> >> >> you
> >> >> >>> are using service client directly it will not append the
> operation
> >> >> >>> name to the EPR. Note that you have to configure the
> ServiceClient
> >> >> >>> your self when using this. (This is not the case for stubs
> >> generated
> >> >> >>> for the httpBinding though).
> >> >> >>>
> >> >> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
> >> >> >>> <ni...@imperial.ac.uk> wrote:
> >> >> >>>>
> >> >> >>>> Thank you Jay and Keith for your replies. I've upgraded to
> >> version
> >> >> >>>> 1.4.1
> >> >> >>>> but
> >> >> >>>> this had made no difference. Below is a really simple version
> of
> >> my
> >> >> >>>> code
> >> >> >>>> taking the options used by Jay in his working service but I can
> >> >> still
> >> >> >>>> only
> >> >> >>>> get the correct response using getGigsIn() with POST, every
> other
> >> >> >>>> combination else fails with:
> >> >> >>>> <soapenv:Reason
> >> >> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> >> >> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference
> >> (EPR)
> >> >> for
> >> >> >>>> the
> >> >> >>>> Operation not found is
> >> >> /NicksGigs-war-Axis2/services/GigListingsService
> >> >> >>>> and
> >> >> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
> >> >> >>>>
> >> >> >>>> SimpleREST.java:
> >> >> >>>> String epr =
> >> >> >>>> "
> >> >>
> >> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
> >> >> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
> >> >> >>>> Options options = portal._getServiceClient().getOptions();
> >> >> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> >> >> Boolean.TRUE);
> >> >> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >> >> >>>> Constants.Configuration.HTTP_METHOD_POST);
> >> >> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
> >> >> >>>>
> >> >>
> >> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
> >> >> >>>>
> >> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
> >> >> >>>> Constants.VALUE_TRUE);
> >> >> >>>> options.setCallTransportCleanup(true);
> >> >> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
> >> >> >>>> portal._getServiceClient().setOptions(options);
> >> >> >>>> Gig[] results = portal.getGigsIn("London");
> >> >> >>>> for (int j = 0; j < results.length; j++)
> >> >> >>>> System.out.println(results[j].getToString());
> >> >> >>>>
> >> >> >>>> Note that I had to comment out the MESSAGE_TYPE property for
> this
> >> to
> >> >> >>>> work. I
> >> >> >>>> have also commented out the SOAP_ACTION property here since
> >> although
> >> >> it
> >> >> >>>> did
> >> >> >>>> remove the action(s) in the header it didn't make any difference
> >> to
> >> >> the
> >> >> >>>> end
> >> >> >>>> result.
> >> >> >>>>
> >> >> >>>> The thing which strikes me most about this is that whether using
> >> GET
> >> >> or
> >> >> >>>> POST
> >> >> >>>> the bindings do not append the method names to the endpoint like
> >> I
> >> >> >>>> would
> >> >> >>>> expect them to. I wrongly assumed that at some point the axis
> >> >> >>>> generated
> >> >> >>>> code would do something like endpoint+"/"+methodName but it
> >> doesn't
> >> >> >>>> seem
> >> >> >>>> to... Is this correct behaviour?
> >> >> >>>>
> >> >> >>>> I took a look at the blog entry and after a closer look at my
> >> WSDL
> >> >> it
> >> >> >>>> seems
> >> >> >>>> that the one generated at
> >> >> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the
> >> >> correct
> >> >> >>>> parameter names, but the wsdl generated by the maven java2wsdl
> >> >> plugin
> >> >> >>>> and
> >> >> >>>> then subsequently used by wsdl2java to create my stub has the
> >> >> param0,
> >> >> >>>> param1
> >> >> >>>> names. Maven automatically compiles with debug on and I've made
> >> no
> >> >> >>>> changes
> >> >> >>>> to this so I am a bit confused why I'm getting this. Even more
> so
> >> by
> >> >> >>>> the
> >> >> >>>> fact that if I create unwrapped bindings then the correct
> >> parameter
> >> >> >>>> names
> >> >> >>>> are used.
> >> >> >>>
> >> >> >>> This is strange. I haven't tried this out though (wsdl2java maven
> >> >> >>> plugin). Would give it a try and let you know.
> >> >> >>>
> >> >> >>> Thanks,
> >> >> >>> Keith.
> >> >> >>>>
> >> >> >>>> Thanks
> >> >> >>>> Nick
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> keith chapman wrote:
> >> >> >>>>>
> >> >> >>>>> Hi Nick,
> >> >> >>>>>
> >> >> >>>>> Sorry I couldn't get back to you sooner. Was held up with some
> >> >> travel
> >> >> >>>>> last week. So here goes, see my comments inline. (As a summary
> >> >> could
> >> >> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this
> >> >> release)
> >> >> >>>>>
> >> >> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
> >> >> >>>>> <ni...@imperial.ac.uk> wrote:
> >> >> >>>>>>
> >> >> >>>>>> Hi,
> >> >> >>>>>>
> >> >> >>>>>> I've recently started looking at using the REST support in
> >> Axis2
> >> >> to
> >> >> >>>>>> invoke
> >> >> >>>>>> my web service instead of the currently used SOAP calls and I
> >> have
> >> >> a
> >> >> >>>>>> number
> >> >> >>>>>> of issues I can't work out for myself. Any help with these
> >> would
> >> >> be
> >> >> >>>>>> great.
> >> >> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in
> >> the
> >> >> >>>>>> hope
> >> >> >>>>>> my
> >> >> >>>>>> issues would be solved) and tcpmon to monitor the traffic
> >> between
> >> >> my
> >> >> >>>>>> test
> >> >> >>>>>> client and my service running locally on tomcat at
> >> >> >
> >> >> >>>>>>
> >> >>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
> >> >> >>>>>> The
> >> >> >>>>>> WSDL is created using java2wsdl and is attached.
> >> >> >>>>>>
> >> >> >>>>>> I've read in another (old) post here that Axis2 is just a soap
> >> >> stack
> >> >> >>>>>> and
> >> >> >>>>>> any
> >> >> >>>>>> incoming rest style messages are converted into soap messages
> >> >> first
> >> >> >>>>>> so
> >> >> >>>>>> that
> >> >> >>>>>> they can then be processed. Is this still the case?
> >> >> >>>>>
> >> >> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message
> >> gets
> >> >> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
> >> >> >>>>> message we do create a SOAP message out of it.
> >> >> >>>>>
> >> >> >>>>> Does this have a
> >> >> >>>>>> performance hit? Is there anything in the documentation about
> >> >> this?
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for
> >> my
> >> >> test
> >> >> >>>>>> client, to use the rest style web calls with the bindings is
> it
> >> >> >>>>>> simply
> >> >> >>>>>> a
> >> >> >>>>>> case of adding the line of code below into my client?
> >> >> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> >> >> >>>>>> Constants.VALUE_TRUE);
> >> >> >>>>>> I want to clarify this since all the examples I have seen do
> >> not
> >> >> use
> >> >> >>>>>> bindings.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> Is it possible to use both POST and GET when my operation
> >> >> parameters
> >> >> >>>>>> are
> >> >> >>>>>> all
> >> >> >>>>>> simple types? To change between the two transports is it
> >> simply
> >> a
> >> >> >>>>>> case
> >> >> >>>>>> of
> >> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >> >> >>>>>> HTTP_METHOD_GET);
> >> >> >>>>>> Or
> >> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >> >> >>>>>> HTTP_METHOD_POST);
> >> >> >>>>>> ?
> >> >> >>>>>
> >> >> >>>>> Yes you could set the HTTP Method you need as explained above.
> >> >> Axis2
> >> >> >>>>> also supports PUT and DELETE.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> I've found that I can use POST with operations that have
> >> >> parameters
> >> >> >>>>>> but
> >> >> >>>>>> not
> >> >> >>>>>> on those without parameters. For example, a call to
> >> >> >>>>>> getGigsIn("London")
> >> >> >>>>>> using HTTP_POST makes the following successful request:
> >> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >> >> >>>>>> Content-Type: application/xml; charset=UTF-8
> >> >> >>>>>> SOAPAction: urn:getGigsIn
> >> >> >>>>>> User-Agent: Axis2
> >> >> >>>>>> Content-Length: 115
> >> >> >>>>>>
> >> >> >>>>>> <ns2:getGigsIn
> >> >> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
> >> >> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
> >> >> >>>>>>
> >> >> >>>>>> But a call to getMostActiveArtist() makes the following
> >> >> unsuccessful
> >> >> >>>>>> request:
> >> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >> >> >>>>>> Content-Type: application/xml; charset=UTF-8
> >> >> >>>>>> SOAPAction: urn:getMostActiveArtist
> >> >> >>>>>> User-Agent: Axis2
> >> >> >>>>>> Content-Length: 0
> >> >> >>>>>>
> >> >> >>>>>> with received error:
> >> >> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation
> not
> >> >> found
> >> >> >>>>>> is
> >> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
> >> >> Action
> >> >> =
> >> >> >>>>>> null</faultstring>
> >> >> >>>>>>
> >> >> >>>>>> Why doesn't this work??
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make
> >> any
> >> >> >>>>>> successful
> >> >> >>>>>> calls to my service. getGigsIn("London") gives:
> >> >> >>>>>> GET
> >> /NicksGigs-war-Axis2/services/GigListingsService?param0=London
> >> >> >>>>>> HTTP/1.1
> >> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >> >> >>>>>> SOAPAction: urn:getGigsIn
> >> >> >>>>>> User-Agent: Axis2
> >> >> >>>>>>
> >> >> >>>>>> <soapenv:Reason
> >> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
> >> >> "><soapenv:Text
> >> >> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the
> Operation
> >> >> not
> >> >> >>>>>> found
> >> >> >>>>>> is
> >> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
> >> >> Action
> >> >> =
> >> >> >>>>>> null</soapenv:Text></soapenv:Reason>
> >> >> >>>>>>
> >> >> >>>>>> while getMostActiveArtist() gives:
> >> >> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >> >> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
> >> >> >>>>>> SOAPAction: urn:getMostActiveArtist
> >> >> >>>>>> User-Agent: Axis2
> >> >> >>>>>>
> >> >> >>>>>> And the same error response.
> >> >> >>>>>>
> >> >> >>>>>> Shouldn't the bindings be appending the operation name onto
> the
> >> >> end
> >> >> >>>>>> of
> >> >> >>>>>> the
> >> >> >>>>>> endpoint for me? If I explicitly set the endpoint to
> >> >> >>>>>>
> >> >>
> >>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
> >> >> >>>>>> it makes the following request:
> >> >> >>>>>> GET
> >> >> >>>>>>
> >> >>
> >> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
> >> >> >>>>>> HTTP/1.1
> >> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >> >> >>>>>> SOAPAction: urn:getGigsIn
> >> >> >>>>>> User-Agent: Axis2
> >> >> >>>>>>
> >> >> >>>>>> Which still gives an error, but this time:
> >> >> >>>>>> <soapenv:Reason
> >> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
> >> >> "><soapenv:Text
> >> >> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke
> >> service
> >> >> >>>>>> method
> >> >> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
> >> >> >>>>>>
> >> >> >>>>>> If I simply go to
> >> >> >>>>>>
> >> >>
> >>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
> >> >> >>>>>> in my browser I get the correct response.
> >> >> >>>>>
> >> >> >>>>> The above should work for you correctly with codegenerated
> >> stubs.
> >> >> Can
> >> >> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on
> REST
> >> >> >>>>> invocation for this release and verified that these stuff work.
> >> >> >>>>>>
> >> >> >>>>>> For me, one of the advantages of the generated bindings is not
> >> >> having
> >> >> >>>>>> to
> >> >> >>>>>> worry about the contents of the WSDL; I shouldn't have to know
> >> >> that
> >> >> >>>>>> the
> >> >> >>>>>> WSDL
> >> >> >>>>>> says I must specify the "city" parameter in my query string
> for
> >> >> the
> >> >> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
> >> >> >>>>>> instead?
> >> >> >>>>>
> >> >> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you
> >> the
> >> >> >>>>> answer to this.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> Finally, the documentation specifies that Axis2 determines if
> >> an
> >> >> >>>>>> incoming
> >> >> >>>>>> message is REST or SOAP by checking if "the content type is
> >> >> text/xml
> >> >> >>>>>> and
> >> >> >>>>>> if
> >> >> >>>>>> the SOAPAction Header is missing". If you examine the
> requests
> >> >> the
> >> >> >>>>>> following headers are present for each method.
> >> >> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
> >> >> >>>>>> HTTP_POST: Just SOAPAction
> >> >> >>>>>> SOAP: Just "action" in Content-Type
> >> >> >>>>>>
> >> >> >>>>>> What is going on here, are these the correct headers? And what
> >> is
> >> >> the
> >> >> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
> >> >> >>>>>> Content-Type!?
> >> >> >>>>>> I also found that when using POST I can even remove the
> >> SOAPAction
> >> >> >>>>>> header
> >> >> >>>>>> but providing I ensure the Content-Type still contains
> >> >> >>>>>> "application/xml"
> >> >> >>>>>> I
> >> >> >>>>>> will still receive the correct (non-soap) response from the
> >> >> service.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> I'm aware I might be doing something fundamentally wrong on
> the
> >> >> >>>>>> client
> >> >> >>>>>> side
> >> >> >>>>>> (maybe you can't use ADB bindings?) to get these results and
> >> I'd
> >> >> be
> >> >> >>>>>> very
> >> >> >>>>>> grateful for any responses to any of these questions.
> >> >> >>>>>
> >> >> >>>>> You can use codegenerated stub to invoke REST services.
> >> >> >>>>>
> >> >> >>>>> Thanks,
> >> >> >>>>> Keith.
> >> >> >>>>>>
> >> >> >>>>>> Thanks,
> >> >> >>>>>> Nick
> >> >> >>>>>> http://www.nabble.com/file/p19087933/example.wsdlexample.wsdl
> >> >> >>>>>> --
> >> >> >>>>>> View this message in context:
> >> >> >>>>>>
> >> >>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
> >> >> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> --
> >> >> >>>>> Keith Chapman
> >> >> >>>>> Senior Software Engineer
> >> >> >>>>> WSO2 Inc.
> >> >> >>>>> Oxygenating the Web Service Platform.
> >> >> >>>>> http://wso2.org/
> >> >> >>>>>
> >> >> >>>>> blog: http://www.keith-chapman.org
> >> >> >>>>>
> >> >> >>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>> --
> >> >> >>>> View this message in context:
> >> >> >>>>
> >> >>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
> >> >> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> Keith Chapman
> >> >> >>> Senior Software Engineer
> >> >> >>> WSO2 Inc.
> >> >> >>> Oxygenating the Web Service Platform.
> >> >> >>> http://wso2.org/
> >> >> >>>
> >> >> >>> blog: http://www.keith-chapman.org
> >> >> >>>
> >> >> >>>
> >> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
> >> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Keith Chapman
> >> >> > Senior Software Engineer
> >> >> > WSO2 Inc.
> >> >> > Oxygenating the Web Service Platform.
> >> >> > http://wso2.org/
> >> >> >
> >> >> > blog: http://www.keith-chapman.org
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Keith Chapman
> >> > Senior Software Engineer
> >> > WSO2 Inc.
> >> > Oxygenating the Web Service Platform.
> >> > http://wso2.org/
> >> >
> >> > blog: http://www.keith-chapman.org
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19285397.html
> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Keith Chapman
> > Senior Software Engineer
> > WSO2 Inc.
> > Oxygenating the Web Service Platform.
> > http://wso2.org/
> >
> > blog: http://www.keith-chapman.org
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19288850.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
Hi again,
I've had a little bit more of a look into my issue with the differing
parameter names between my two WSDLs and realised what's happening. My
services.xml looks like the following:
<service name="GigListingsService">
<description>Nicks Gig Service.</description>
<parameter
name="ServiceObjectSupplier">org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier</parameter>
<parameter name="SpringBeanName">gigListingsService</parameter>
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
</messageReceivers>
</service>
And the Spring context defines the gigListingsService bean as my
GigListingsImpl concrete class. So when generating the runtime WSDL at
http://<service url>?wsdl Axis uses the implementation class and is able to
extract the correct parameter names for the WSDL. But when I generate the
WSDL using Maven's java2wsdl plugin I am specifying the interface class:
GigListings, and from what I have read elsewhere it is not possible to
extract parameter names from a Java interface (or abstract class for that
matter) - this is a Java issue/feature/thing.
If I add the ServiceClass parameter to my services.xml and specify it as the
GigListings interface then the runtime WSDL also has the incorrect parameter
names. It makes a lot more sense to generate a WSDL from the interface
rather than the implementation class, one reason being that there may be
additional public methods in GigListingsImpl that should not be visible to
web service users in the WSDL. This is not made clear in the "Axis2
Integration with the Spring Framework" documentation.
The real problem for me then comes when I try to use REST with GET since the
incorrect parameter names are used in the query string as the stub has no
idea of the real ones. E.g. the request should be:
<service url>/getGigsIn?city=London
but it ends up being:
<service url>/getGigsIn?param0=London
which fails with the returned error: "Exception occurred while trying to
invoke service method getGigsIn"
When doing REST with POST, the request also uses param0 but this time
without any problem.
<ns2:getGigsIn
xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
You can in fact substitute param0 for anything you want and it still works.
Why is this behaviour different between GET and POST? Is there a solution
to my problem?
Thanks,
Nick
Nick Steel wrote:
>
> As you can see from my previously attached wsdls (which are generated
> using Maven java2wsdl) the getGigsIn element has one parameter called
> "param0" so it wouldn't be surprising to find the stub using this
> parameter name. However, the wsdl generated at runtime by visiting
> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl (
> http://www.nabble.com/file/p19288850/GigListingsService-generated_at_runtime.wsdl
> GigListingsService-generated_at_runtime.wsdl ) correctly describes the
> parameter as being called "city". As far as I can tell debug is enabled
> by default when using Maven
> (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html)
> but perhaps it is using a different source to wsdl generated at runtime?
> The source class being used is an interface, could this be a problem?
>
> Since my wsdl is generated by Maven, and then client stubs from that to do
> testing, during build the idea of having to manually modify the wsdl to
> change operations to GET/PUT whatever is a little awkward. Is it possible
> to annotate the Java service class interface used by java2wsdl so that it
> can automatically detect which http method is needed for an operation?
>
> I didn't have any experience with web services before I started using
> Axis2 a couple of months ago so maybe I am missing something here but it
> would be handy if in the stubs there was a way to easily change between
> GET, POST, PUT and DELETE. This would then set all the properties you
> needed for it to work. Would this be something possible in the future?
>
> Nick
>
>
> keith chapman wrote:
>>
>> Hi Nick,
>>
>> Looking through the WSDLs I don't see any reason for the input/output
>> types
>> in the stub to go missing when generated off a WSDL 1.1 doc. I may have
>> to
>> test this to make sure that this is the case though. On the subject of a
>> particular operation not working when invoked via GET. In a previous mail
>> you said that " I have now generated the httpbindings using wsdl2java
>> with a
>> version 2.0 wsdl and the operation has been added to the EPR as desired
>> and
>> I can do POST getGigsIn("London"), POST getMostActiveArtist() and GET
>> getMostActiveArtist() without any problems which is great. "
>>
>> How did you send a GET to getMostActiveArtist()? I assume that you set
>> the
>> httpmethod on the options object of the serviceClient to GET (cause the
>> stub
>> will send a POST by default according to the WSDL). Could you please
>> explain
>> a bit what you did to send that request. I just had a look at the code
>> and
>> when its a GET or a DELETE we use the application/x-www-form-urlencoded
>> as
>> the content-type. (BTW which version of axis2 did u use?)
>>
>> The default WSDL generated by axis2 will have all operations exposed over
>> POST with the inputSerialization of application/XML. If you need to
>> change
>> this (expose some operations over GET) you may do so by hand editing the
>> generated WSDL and using that. This may be better cause you choose which
>> method you want to expose your operations under.
>>
>> Thanks,
>> Keith.
>>
>> On Wed, Sep 3, 2008 at 2:28 PM, Nick Steel
>> <ni...@imperial.ac.uk>wrote:
>>
>>>
>>> Keith,
>>>
>>> Please find both versions of my wsdl attached. Note that these are the
>>> files generated using Maven java2wsdl at buildtime that I then go on to
>>> use
>>> with Maven wsdl2java to get my client stubs.
>>> http://www.nabble.com/file/p19285397/NicksGigs.wsdl NicksGigs.wsdl
>>> http://www.nabble.com/file/p19285397/NicksGigsV2.wsdl NicksGigsV2.wsdl
>>>
>>> Ad you can see my wsdl doesn't contain any inputSerialization fields at
>>> all.
>>> And the method seems to be POST be default, is this the problem?
>>>
>>> Nick
>>>
>>>
>>> keith chapman wrote:
>>> >
>>> > Hi Nick,
>>> >
>>> > See My comments inline
>>> >
>>> > On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel
>>> > <nicholas.steel05@imperial.ac.uk
>>> >> wrote:
>>> >
>>> >>
>>> >> I have now generated the httpbindings using wsdl2java with a version
>>> 2.0
>>> >> wsdl
>>> >> and the operation has been added to the EPR as desired and I can do
>>> POST
>>> >> getGigsIn("London"), POST getMostActiveArtist() and GET
>>> >> getMostActiveArtist() without any problems which is great.
>>> >
>>> >
>>> > Cool, thats good news.
>>> >
>>> >
>>> >> The headers for
>>> >> both GET and POST are also now the same (see below) which makes a lot
>>> >> more
>>> >> sense to me.
>>> >> Content-Type: application/xml; charset=UTF-8
>>> >> SOAPAction: ""
>>> >>
>>> >
>>> > I've already opened a JIRA against axis2 for the above. The client
>>> should
>>> > not sent the SOAP action when it is a REST request. Will fix this soon
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >> However, when I try to do GET getGigsIn("London") I get the error
>>> >> <faultstring>unknown</faultstring>. The request according to TCPmon
>>> is:
>>> >> GET
>>> >>
>>> >>
>>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
>>> >> HTTP/1.1
>>> >> Content-Type: application/xml; charset=UTF-8
>>> >> SOAPAction: ""
>>> >> User-Agent: Axis2
>>> >> Host: 10.4.39.241:8089
>>> >
>>> >
>>> > Something is obviously wrong here. You cannot send a GET using
>>> > application/xml. A get should always be
>>> application/x-www-form-urlencoded.
>>> > Can yu check your WSDL2 section for this operation please. Does it say
>>> > what
>>> > its inputSerialization is?
>>> >
>>> >
>>> >> <http://10.4.39.241:8089>
>>> >>
>>> >> The operation is there in the URL but the parameter "London" is not
>>> so
>>> >> it's
>>> >> obviously not going to work. I was expecting something more like
>>> >> GET
>>> >>
>>> >>
>>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
>>> >> HTTP/1.1
>>> >>
>>> >> Whats going wrong here?
>>> >
>>> >
>>> > Just answered above ;).
>>> >
>>> >>
>>> >>
>>> >> Also, just to see what would happen, I tried to make some
>>> httpbindings
>>> >> using
>>> >> a version 1.1 wsdl but the generated stub had methods like void
>>> >> getGigsIn()
>>> >> and void getMostActiveArtist() which don't take or return any values
>>> so
>>> I
>>> >> couldn't work out how I could possibly use them. Is this normal or
>>> is
>>> >> this
>>> >> the reason you said to use a version 2.0 wsdl?httpBinding.
>>> >>
>>> >
>>> > WSDL 2.0 has a much richer That is the reason I recommended you to use
>>> > that.
>>> > But ?wsdl should have worked as well, we map the properties of ?wsdl
>>> to
>>> > the
>>> > ones of ?wsdl2 during code generation. Is it possible for you to share
>>> > your
>>> > wsdl and wsdl2 as well.
>>> >
>>> > Thanks,
>>> > Keith.
>>> >
>>> >
>>> >>
>>> >>
>>> >> Cheers,
>>> >> Nick
>>> >>
>>> >>
>>> >> keith chapman wrote:
>>> >> >
>>> >> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
>>> >> > <ni...@imperial.ac.uk> wrote:
>>> >> >>
>>> >> >> Keith,
>>> >> >>
>>> >> >> I had no idea ?wsdl2 even existed,
>>> >> >
>>> >> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
>>> >> > HTTPBinding can describe a REST interface for your service in a
>>> nice
>>> >> > manner.
>>> >> >
>>> >> > I've no idea how I managed to miss this
>>> >> >> but I will hunt for it tomorrow and give it a go. Thanks very
>>> much
>>> >> this
>>> >> >> reply, what you say aout the EPR has definitely cleared some
>>> things
>>> up
>>> >> >> for
>>> >> >> me and hopefully I can now go on to get this to work.
>>> >> >>
>>> >> >> Just to be clear though, you say I should generate the client stub
>>> for
>>> >> >> the
>>> >> >> httpbinding, how exactly do I do this? I thought the stub I
>>> already
>>> >> had
>>> >> >> could handle all the bindings in my wsdl and that setting the
>>> portal
>>> >> >> parameters was what controlled which binding was being used. Is
>>> this
>>> >> >> wrong?
>>> >> >
>>> >> > When codegeneration is used to generate the server side code its
>>> only
>>> >> > the portType (or the interface if WSDL 2.0) that we care about when
>>> >> > generating code. But when its generating code for the client side
>>> we
>>> >> > generate it for a particular port and you can specify this by using
>>> >> > the -pn option. If a port if not provided it faults to use the
>>> first
>>> >> > SOAP 1.2 port it finds. You could generate code for all ports too
>>> this
>>> >> > can be done by using the -ap options. This will generate stubs for
>>> all
>>> >> > ports in the WSDL. So for example if I take the same RESTSample
>>> that I
>>> >> > used yesterday this is how I would generate code for its
>>> HTTPBinding.
>>> >> >
>>> >> > wsdl2java.sh -uri
>>> http://mooshup.com/services/samples/RESTSample?wsdl2
>>> >> > -pn HTTPEndpoint -wv 2
>>> >> >
>>> >> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
>>> >> >
>>> >> > Thanks,
>>> >> > Keith.
>>> >> >>
>>> >> >> Cheers,
>>> >> >> Nick
>>> >> >>
>>> >> >>
>>> >> >> keith chapman wrote:
>>> >> >>>
>>> >> >>> Hi Nick,
>>> >> >>>
>>> >> >>> If you want to invoke a service using REST then its better to
>>> >> generate
>>> >> >>> the client stub for the httpBinding (and when doing so I
>>> recommend
>>> >> you
>>> >> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
>>> >> >>> interface of the service. This is where it will contain details
>>> of
>>> >> the
>>> >> >>> URL the operation is available at hence if this binding is used
>>> to
>>> >> >>> invoke the service it will automatically add the operation name
>>> to
>>> >> the
>>> >> >>> end of the EPR. This does not happen for the SOAP bindings
>>> though.
>>> >> >>> This is the reason for the behavior you observed below.
>>> >> >>>
>>> >> >>> In the request you have sent below does not contain enough
>>> >> information
>>> >> >>> to dispatch it to the correct operation of the service. If you
>>> had
>>> >> the
>>> >> >>> operation name at the end of it it would have worked. And BTW
>>> when
>>> >> you
>>> >> >>> are using service client directly it will not append the
>>> operation
>>> >> >>> name to the EPR. Note that you have to configure the
>>> ServiceClient
>>> >> >>> your self when using this. (This is not the case for stubs
>>> generated
>>> >> >>> for the httpBinding though).
>>> >> >>>
>>> >> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
>>> >> >>> <ni...@imperial.ac.uk> wrote:
>>> >> >>>>
>>> >> >>>> Thank you Jay and Keith for your replies. I've upgraded to
>>> version
>>> >> >>>> 1.4.1
>>> >> >>>> but
>>> >> >>>> this had made no difference. Below is a really simple version
>>> of
>>> my
>>> >> >>>> code
>>> >> >>>> taking the options used by Jay in his working service but I can
>>> >> still
>>> >> >>>> only
>>> >> >>>> get the correct response using getGigsIn() with POST, every
>>> other
>>> >> >>>> combination else fails with:
>>> >> >>>> <soapenv:Reason
>>> >> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>>> >> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference
>>> (EPR)
>>> >> for
>>> >> >>>> the
>>> >> >>>> Operation not found is
>>> >> /NicksGigs-war-Axis2/services/GigListingsService
>>> >> >>>> and
>>> >> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>>> >> >>>>
>>> >> >>>> SimpleREST.java:
>>> >> >>>> String epr =
>>> >> >>>> "
>>> >>
>>> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>>> >> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>>> >> >>>> Options options = portal._getServiceClient().getOptions();
>>> >> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>>> >> Boolean.TRUE);
>>> >> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>> >> >>>> Constants.Configuration.HTTP_METHOD_POST);
>>> >> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>>> >> >>>>
>>> >>
>>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>>> >> >>>>
>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>>> >> >>>> Constants.VALUE_TRUE);
>>> >> >>>> options.setCallTransportCleanup(true);
>>> >> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>>> >> >>>> portal._getServiceClient().setOptions(options);
>>> >> >>>> Gig[] results = portal.getGigsIn("London");
>>> >> >>>> for (int j = 0; j < results.length; j++)
>>> >> >>>> System.out.println(results[j].getToString());
>>> >> >>>>
>>> >> >>>> Note that I had to comment out the MESSAGE_TYPE property for
>>> this
>>> to
>>> >> >>>> work. I
>>> >> >>>> have also commented out the SOAP_ACTION property here since
>>> although
>>> >> it
>>> >> >>>> did
>>> >> >>>> remove the action(s) in the header it didn't make any difference
>>> to
>>> >> the
>>> >> >>>> end
>>> >> >>>> result.
>>> >> >>>>
>>> >> >>>> The thing which strikes me most about this is that whether using
>>> GET
>>> >> or
>>> >> >>>> POST
>>> >> >>>> the bindings do not append the method names to the endpoint like
>>> I
>>> >> >>>> would
>>> >> >>>> expect them to. I wrongly assumed that at some point the axis
>>> >> >>>> generated
>>> >> >>>> code would do something like endpoint+"/"+methodName but it
>>> doesn't
>>> >> >>>> seem
>>> >> >>>> to... Is this correct behaviour?
>>> >> >>>>
>>> >> >>>> I took a look at the blog entry and after a closer look at my
>>> WSDL
>>> >> it
>>> >> >>>> seems
>>> >> >>>> that the one generated at
>>> >> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the
>>> >> correct
>>> >> >>>> parameter names, but the wsdl generated by the maven java2wsdl
>>> >> plugin
>>> >> >>>> and
>>> >> >>>> then subsequently used by wsdl2java to create my stub has the
>>> >> param0,
>>> >> >>>> param1
>>> >> >>>> names. Maven automatically compiles with debug on and I've made
>>> no
>>> >> >>>> changes
>>> >> >>>> to this so I am a bit confused why I'm getting this. Even more
>>> so
>>> by
>>> >> >>>> the
>>> >> >>>> fact that if I create unwrapped bindings then the correct
>>> parameter
>>> >> >>>> names
>>> >> >>>> are used.
>>> >> >>>
>>> >> >>> This is strange. I haven't tried this out though (wsdl2java maven
>>> >> >>> plugin). Would give it a try and let you know.
>>> >> >>>
>>> >> >>> Thanks,
>>> >> >>> Keith.
>>> >> >>>>
>>> >> >>>> Thanks
>>> >> >>>> Nick
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> keith chapman wrote:
>>> >> >>>>>
>>> >> >>>>> Hi Nick,
>>> >> >>>>>
>>> >> >>>>> Sorry I couldn't get back to you sooner. Was held up with some
>>> >> travel
>>> >> >>>>> last week. So here goes, see my comments inline. (As a summary
>>> >> could
>>> >> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this
>>> >> release)
>>> >> >>>>>
>>> >> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>>> >> >>>>> <ni...@imperial.ac.uk> wrote:
>>> >> >>>>>>
>>> >> >>>>>> Hi,
>>> >> >>>>>>
>>> >> >>>>>> I've recently started looking at using the REST support in
>>> Axis2
>>> >> to
>>> >> >>>>>> invoke
>>> >> >>>>>> my web service instead of the currently used SOAP calls and I
>>> have
>>> >> a
>>> >> >>>>>> number
>>> >> >>>>>> of issues I can't work out for myself. Any help with these
>>> would
>>> >> be
>>> >> >>>>>> great.
>>> >> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in
>>> the
>>> >> >>>>>> hope
>>> >> >>>>>> my
>>> >> >>>>>> issues would be solved) and tcpmon to monitor the traffic
>>> between
>>> >> my
>>> >> >>>>>> test
>>> >> >>>>>> client and my service running locally on tomcat at
>>> >> >
>>> >> >>>>>>
>>> >>
>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>>> >> >>>>>> The
>>> >> >>>>>> WSDL is created using java2wsdl and is attached.
>>> >> >>>>>>
>>> >> >>>>>> I've read in another (old) post here that Axis2 is just a soap
>>> >> stack
>>> >> >>>>>> and
>>> >> >>>>>> any
>>> >> >>>>>> incoming rest style messages are converted into soap messages
>>> >> first
>>> >> >>>>>> so
>>> >> >>>>>> that
>>> >> >>>>>> they can then be processed. Is this still the case?
>>> >> >>>>>
>>> >> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message
>>> gets
>>> >> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>>> >> >>>>> message we do create a SOAP message out of it.
>>> >> >>>>>
>>> >> >>>>> Does this have a
>>> >> >>>>>> performance hit? Is there anything in the documentation about
>>> >> this?
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for
>>> my
>>> >> test
>>> >> >>>>>> client, to use the rest style web calls with the bindings is
>>> it
>>> >> >>>>>> simply
>>> >> >>>>>> a
>>> >> >>>>>> case of adding the line of code below into my client?
>>> >> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>>> >> >>>>>> Constants.VALUE_TRUE);
>>> >> >>>>>> I want to clarify this since all the examples I have seen do
>>> not
>>> >> use
>>> >> >>>>>> bindings.
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> Is it possible to use both POST and GET when my operation
>>> >> parameters
>>> >> >>>>>> are
>>> >> >>>>>> all
>>> >> >>>>>> simple types? To change between the two transports is it
>>> simply
>>> a
>>> >> >>>>>> case
>>> >> >>>>>> of
>>> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>> >> >>>>>> HTTP_METHOD_GET);
>>> >> >>>>>> Or
>>> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>> >> >>>>>> HTTP_METHOD_POST);
>>> >> >>>>>> ?
>>> >> >>>>>
>>> >> >>>>> Yes you could set the HTTP Method you need as explained above.
>>> >> Axis2
>>> >> >>>>> also supports PUT and DELETE.
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> I've found that I can use POST with operations that have
>>> >> parameters
>>> >> >>>>>> but
>>> >> >>>>>> not
>>> >> >>>>>> on those without parameters. For example, a call to
>>> >> >>>>>> getGigsIn("London")
>>> >> >>>>>> using HTTP_POST makes the following successful request:
>>> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>> >> >>>>>> Content-Type: application/xml; charset=UTF-8
>>> >> >>>>>> SOAPAction: urn:getGigsIn
>>> >> >>>>>> User-Agent: Axis2
>>> >> >>>>>> Content-Length: 115
>>> >> >>>>>>
>>> >> >>>>>> <ns2:getGigsIn
>>> >> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
>>> >> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>>> >> >>>>>>
>>> >> >>>>>> But a call to getMostActiveArtist() makes the following
>>> >> unsuccessful
>>> >> >>>>>> request:
>>> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>> >> >>>>>> Content-Type: application/xml; charset=UTF-8
>>> >> >>>>>> SOAPAction: urn:getMostActiveArtist
>>> >> >>>>>> User-Agent: Axis2
>>> >> >>>>>> Content-Length: 0
>>> >> >>>>>>
>>> >> >>>>>> with received error:
>>> >> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation
>>> not
>>> >> found
>>> >> >>>>>> is
>>> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>>> >> Action
>>> >> =
>>> >> >>>>>> null</faultstring>
>>> >> >>>>>>
>>> >> >>>>>> Why doesn't this work??
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make
>>> any
>>> >> >>>>>> successful
>>> >> >>>>>> calls to my service. getGigsIn("London") gives:
>>> >> >>>>>> GET
>>> /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>>> >> >>>>>> HTTP/1.1
>>> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>>> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>>> >> >>>>>> SOAPAction: urn:getGigsIn
>>> >> >>>>>> User-Agent: Axis2
>>> >> >>>>>>
>>> >> >>>>>> <soapenv:Reason
>>> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>>> >> "><soapenv:Text
>>> >> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the
>>> Operation
>>> >> not
>>> >> >>>>>> found
>>> >> >>>>>> is
>>> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>>> >> Action
>>> >> =
>>> >> >>>>>> null</soapenv:Text></soapenv:Reason>
>>> >> >>>>>>
>>> >> >>>>>> while getMostActiveArtist() gives:
>>> >> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>>> >> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>>> >> >>>>>> SOAPAction: urn:getMostActiveArtist
>>> >> >>>>>> User-Agent: Axis2
>>> >> >>>>>>
>>> >> >>>>>> And the same error response.
>>> >> >>>>>>
>>> >> >>>>>> Shouldn't the bindings be appending the operation name onto
>>> the
>>> >> end
>>> >> >>>>>> of
>>> >> >>>>>> the
>>> >> >>>>>> endpoint for me? If I explicitly set the endpoint to
>>> >> >>>>>>
>>> >>
>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>>> >> >>>>>> it makes the following request:
>>> >> >>>>>> GET
>>> >> >>>>>>
>>> >>
>>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>>> >> >>>>>> HTTP/1.1
>>> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>>> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>>> >> >>>>>> SOAPAction: urn:getGigsIn
>>> >> >>>>>> User-Agent: Axis2
>>> >> >>>>>>
>>> >> >>>>>> Which still gives an error, but this time:
>>> >> >>>>>> <soapenv:Reason
>>> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>>> >> "><soapenv:Text
>>> >> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke
>>> service
>>> >> >>>>>> method
>>> >> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>>> >> >>>>>>
>>> >> >>>>>> If I simply go to
>>> >> >>>>>>
>>> >>
>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>>> >> >>>>>> in my browser I get the correct response.
>>> >> >>>>>
>>> >> >>>>> The above should work for you correctly with codegenerated
>>> stubs.
>>> >> Can
>>> >> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on
>>> REST
>>> >> >>>>> invocation for this release and verified that these stuff work.
>>> >> >>>>>>
>>> >> >>>>>> For me, one of the advantages of the generated bindings is not
>>> >> having
>>> >> >>>>>> to
>>> >> >>>>>> worry about the contents of the WSDL; I shouldn't have to know
>>> >> that
>>> >> >>>>>> the
>>> >> >>>>>> WSDL
>>> >> >>>>>> says I must specify the "city" parameter in my query string
>>> for
>>> >> the
>>> >> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
>>> >> >>>>>> instead?
>>> >> >>>>>
>>> >> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you
>>> the
>>> >> >>>>> answer to this.
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> Finally, the documentation specifies that Axis2 determines if
>>> an
>>> >> >>>>>> incoming
>>> >> >>>>>> message is REST or SOAP by checking if "the content type is
>>> >> text/xml
>>> >> >>>>>> and
>>> >> >>>>>> if
>>> >> >>>>>> the SOAPAction Header is missing". If you examine the
>>> requests
>>> >> the
>>> >> >>>>>> following headers are present for each method.
>>> >> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>>> >> >>>>>> HTTP_POST: Just SOAPAction
>>> >> >>>>>> SOAP: Just "action" in Content-Type
>>> >> >>>>>>
>>> >> >>>>>> What is going on here, are these the correct headers? And what
>>> is
>>> >> the
>>> >> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>>> >> >>>>>> Content-Type!?
>>> >> >>>>>> I also found that when using POST I can even remove the
>>> SOAPAction
>>> >> >>>>>> header
>>> >> >>>>>> but providing I ensure the Content-Type still contains
>>> >> >>>>>> "application/xml"
>>> >> >>>>>> I
>>> >> >>>>>> will still receive the correct (non-soap) response from the
>>> >> service.
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> I'm aware I might be doing something fundamentally wrong on
>>> the
>>> >> >>>>>> client
>>> >> >>>>>> side
>>> >> >>>>>> (maybe you can't use ADB bindings?) to get these results and
>>> I'd
>>> >> be
>>> >> >>>>>> very
>>> >> >>>>>> grateful for any responses to any of these questions.
>>> >> >>>>>
>>> >> >>>>> You can use codegenerated stub to invoke REST services.
>>> >> >>>>>
>>> >> >>>>> Thanks,
>>> >> >>>>> Keith.
>>> >> >>>>>>
>>> >> >>>>>> Thanks,
>>> >> >>>>>> Nick
>>> >> >>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>>> >> >>>>>> --
>>> >> >>>>>> View this message in context:
>>> >> >>>>>>
>>> >>
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>>> >> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> ---------------------------------------------------------------------
>>> >> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> --
>>> >> >>>>> Keith Chapman
>>> >> >>>>> Senior Software Engineer
>>> >> >>>>> WSO2 Inc.
>>> >> >>>>> Oxygenating the Web Service Platform.
>>> >> >>>>> http://wso2.org/
>>> >> >>>>>
>>> >> >>>>> blog: http://www.keith-chapman.org
>>> >> >>>>>
>>> >> >>>>>
>>> >> ---------------------------------------------------------------------
>>> >> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> View this message in context:
>>> >> >>>>
>>> >>
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>>> >> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> ---------------------------------------------------------------------
>>> >> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >> >>>>
>>> >> >>>>
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> Keith Chapman
>>> >> >>> Senior Software Engineer
>>> >> >>> WSO2 Inc.
>>> >> >>> Oxygenating the Web Service Platform.
>>> >> >>> http://wso2.org/
>>> >> >>>
>>> >> >>> blog: http://www.keith-chapman.org
>>> >> >>>
>>> >> >>>
>>> ---------------------------------------------------------------------
>>> >> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >> --
>>> >> >> View this message in context:
>>> >> >>
>>> >>
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
>>> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
>>> >> >>
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Keith Chapman
>>> >> > Senior Software Engineer
>>> >> > WSO2 Inc.
>>> >> > Oxygenating the Web Service Platform.
>>> >> > http://wso2.org/
>>> >> >
>>> >> > blog: http://www.keith-chapman.org
>>> >> >
>>> >> >
>>> ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
>>> >> Sent from the Axis - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Keith Chapman
>>> > Senior Software Engineer
>>> > WSO2 Inc.
>>> > Oxygenating the Web Service Platform.
>>> > http://wso2.org/
>>> >
>>> > blog: http://www.keith-chapman.org
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19285397.html
>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>> Keith Chapman
>> Senior Software Engineer
>> WSO2 Inc.
>> Oxygenating the Web Service Platform.
>> http://wso2.org/
>>
>> blog: http://www.keith-chapman.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19334925.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
Thanks for your speedy reply Keith. I have been using the following code to
test today:
String epr =
"http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
portal = new NicksGigsServiceV2Stub(epr);
Options options = portal._getServiceClient().getOptions();
options.setProperty(Constants.Configuration.HTTP_METHOD,
Constants.Configuration.HTTP_METHOD_GET);
int countResults = getGigsIn("London").length;
System.out.println("Found " + countResults + " results.");
After having another look at the generated stub I can see that POST,
application/XML and a load of other properties are hard coded in each
method. I had originally assumed that axis would have changed the
CONTENT_TYPE to the correct one for my chosen HTTP_METHOD further down the
line before sending, but (I'm guessing) this doesn't happen in order to
remain flexible.
I just tried adding
options.setProperty(Constants.Configuration.CONTENT_TYPE,"application/x-www-form-urlencoded");
to my code which now appends the parameter (great!) but I'm back to one of
my original problems in that it's using "param0" instead of "city" in the
query string. The request is below.
GET /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
SOAPAction: ""
User-Agent: Axis2
Host: localhost:8089
As you can see from my previously attached wsdls (which are generated using
Maven java2wsdl) the getGigsIn element has one parameter called "param0" so
it wouldn't be surprising to find the stub using this parameter name.
However, the wsdl generated at runtime by visiting
...NicksGigs-war-Axis2/services/GigListingsService?wsdl (
http://www.nabble.com/file/p19288850/GigListingsService-generated_at_runtime.wsdl
GigListingsService-generated_at_runtime.wsdl ) correctly describes the
parameter as being called "city". As far as I can tell debug is enabled by
default when using Maven
(http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html)
but perhaps it is using a different source to wsdl generated at runtime?
The source class being used is an interface, could this be a problem?
Since my wsdl is generated by Maven, and then client stubs from that to do
testing, during build the idea of having to manually modify the wsdl to
change operations to GET/PUT whatever is a little awkward. Is it possible
to annotate the Java service class interface used by java2wsdl so that it
can automatically detect which http method is needed for an operation?
I didn't have any experience with web services before I started using Axis2
a couple of months ago so maybe I am missing something here but it would be
handy if in the stubs there was a way to easily change between GET, POST,
PUT and DELETE. This would then set all the properties you needed for it to
work. Would this be something possible in the future?
Nick
keith chapman wrote:
>
> Hi Nick,
>
> Looking through the WSDLs I don't see any reason for the input/output
> types
> in the stub to go missing when generated off a WSDL 1.1 doc. I may have to
> test this to make sure that this is the case though. On the subject of a
> particular operation not working when invoked via GET. In a previous mail
> you said that " I have now generated the httpbindings using wsdl2java with
> a
> version 2.0 wsdl and the operation has been added to the EPR as desired
> and
> I can do POST getGigsIn("London"), POST getMostActiveArtist() and GET
> getMostActiveArtist() without any problems which is great. "
>
> How did you send a GET to getMostActiveArtist()? I assume that you set the
> httpmethod on the options object of the serviceClient to GET (cause the
> stub
> will send a POST by default according to the WSDL). Could you please
> explain
> a bit what you did to send that request. I just had a look at the code and
> when its a GET or a DELETE we use the application/x-www-form-urlencoded as
> the content-type. (BTW which version of axis2 did u use?)
>
> The default WSDL generated by axis2 will have all operations exposed over
> POST with the inputSerialization of application/XML. If you need to change
> this (expose some operations over GET) you may do so by hand editing the
> generated WSDL and using that. This may be better cause you choose which
> method you want to expose your operations under.
>
> Thanks,
> Keith.
>
> On Wed, Sep 3, 2008 at 2:28 PM, Nick Steel
> <ni...@imperial.ac.uk>wrote:
>
>>
>> Keith,
>>
>> Please find both versions of my wsdl attached. Note that these are the
>> files generated using Maven java2wsdl at buildtime that I then go on to
>> use
>> with Maven wsdl2java to get my client stubs.
>> http://www.nabble.com/file/p19285397/NicksGigs.wsdl NicksGigs.wsdl
>> http://www.nabble.com/file/p19285397/NicksGigsV2.wsdl NicksGigsV2.wsdl
>>
>> Ad you can see my wsdl doesn't contain any inputSerialization fields at
>> all.
>> And the method seems to be POST be default, is this the problem?
>>
>> Nick
>>
>>
>> keith chapman wrote:
>> >
>> > Hi Nick,
>> >
>> > See My comments inline
>> >
>> > On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel
>> > <nicholas.steel05@imperial.ac.uk
>> >> wrote:
>> >
>> >>
>> >> I have now generated the httpbindings using wsdl2java with a version
>> 2.0
>> >> wsdl
>> >> and the operation has been added to the EPR as desired and I can do
>> POST
>> >> getGigsIn("London"), POST getMostActiveArtist() and GET
>> >> getMostActiveArtist() without any problems which is great.
>> >
>> >
>> > Cool, thats good news.
>> >
>> >
>> >> The headers for
>> >> both GET and POST are also now the same (see below) which makes a lot
>> >> more
>> >> sense to me.
>> >> Content-Type: application/xml; charset=UTF-8
>> >> SOAPAction: ""
>> >>
>> >
>> > I've already opened a JIRA against axis2 for the above. The client
>> should
>> > not sent the SOAP action when it is a REST request. Will fix this soon
>> >
>> >
>> >>
>> >>
>> >>
>> >> However, when I try to do GET getGigsIn("London") I get the error
>> >> <faultstring>unknown</faultstring>. The request according to TCPmon
>> is:
>> >> GET
>> >>
>> >>
>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
>> >> HTTP/1.1
>> >> Content-Type: application/xml; charset=UTF-8
>> >> SOAPAction: ""
>> >> User-Agent: Axis2
>> >> Host: 10.4.39.241:8089
>> >
>> >
>> > Something is obviously wrong here. You cannot send a GET using
>> > application/xml. A get should always be
>> application/x-www-form-urlencoded.
>> > Can yu check your WSDL2 section for this operation please. Does it say
>> > what
>> > its inputSerialization is?
>> >
>> >
>> >> <http://10.4.39.241:8089>
>> >>
>> >> The operation is there in the URL but the parameter "London" is not so
>> >> it's
>> >> obviously not going to work. I was expecting something more like
>> >> GET
>> >>
>> >>
>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
>> >> HTTP/1.1
>> >>
>> >> Whats going wrong here?
>> >
>> >
>> > Just answered above ;).
>> >
>> >>
>> >>
>> >> Also, just to see what would happen, I tried to make some httpbindings
>> >> using
>> >> a version 1.1 wsdl but the generated stub had methods like void
>> >> getGigsIn()
>> >> and void getMostActiveArtist() which don't take or return any values
>> so
>> I
>> >> couldn't work out how I could possibly use them. Is this normal or is
>> >> this
>> >> the reason you said to use a version 2.0 wsdl?httpBinding.
>> >>
>> >
>> > WSDL 2.0 has a much richer That is the reason I recommended you to use
>> > that.
>> > But ?wsdl should have worked as well, we map the properties of ?wsdl to
>> > the
>> > ones of ?wsdl2 during code generation. Is it possible for you to share
>> > your
>> > wsdl and wsdl2 as well.
>> >
>> > Thanks,
>> > Keith.
>> >
>> >
>> >>
>> >>
>> >> Cheers,
>> >> Nick
>> >>
>> >>
>> >> keith chapman wrote:
>> >> >
>> >> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
>> >> > <ni...@imperial.ac.uk> wrote:
>> >> >>
>> >> >> Keith,
>> >> >>
>> >> >> I had no idea ?wsdl2 even existed,
>> >> >
>> >> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
>> >> > HTTPBinding can describe a REST interface for your service in a nice
>> >> > manner.
>> >> >
>> >> > I've no idea how I managed to miss this
>> >> >> but I will hunt for it tomorrow and give it a go. Thanks very much
>> >> this
>> >> >> reply, what you say aout the EPR has definitely cleared some things
>> up
>> >> >> for
>> >> >> me and hopefully I can now go on to get this to work.
>> >> >>
>> >> >> Just to be clear though, you say I should generate the client stub
>> for
>> >> >> the
>> >> >> httpbinding, how exactly do I do this? I thought the stub I already
>> >> had
>> >> >> could handle all the bindings in my wsdl and that setting the
>> portal
>> >> >> parameters was what controlled which binding was being used. Is
>> this
>> >> >> wrong?
>> >> >
>> >> > When codegeneration is used to generate the server side code its
>> only
>> >> > the portType (or the interface if WSDL 2.0) that we care about when
>> >> > generating code. But when its generating code for the client side we
>> >> > generate it for a particular port and you can specify this by using
>> >> > the -pn option. If a port if not provided it faults to use the first
>> >> > SOAP 1.2 port it finds. You could generate code for all ports too
>> this
>> >> > can be done by using the -ap options. This will generate stubs for
>> all
>> >> > ports in the WSDL. So for example if I take the same RESTSample that
>> I
>> >> > used yesterday this is how I would generate code for its
>> HTTPBinding.
>> >> >
>> >> > wsdl2java.sh -uri
>> http://mooshup.com/services/samples/RESTSample?wsdl2
>> >> > -pn HTTPEndpoint -wv 2
>> >> >
>> >> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
>> >> >
>> >> > Thanks,
>> >> > Keith.
>> >> >>
>> >> >> Cheers,
>> >> >> Nick
>> >> >>
>> >> >>
>> >> >> keith chapman wrote:
>> >> >>>
>> >> >>> Hi Nick,
>> >> >>>
>> >> >>> If you want to invoke a service using REST then its better to
>> >> generate
>> >> >>> the client stub for the httpBinding (and when doing so I recommend
>> >> you
>> >> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
>> >> >>> interface of the service. This is where it will contain details of
>> >> the
>> >> >>> URL the operation is available at hence if this binding is used to
>> >> >>> invoke the service it will automatically add the operation name to
>> >> the
>> >> >>> end of the EPR. This does not happen for the SOAP bindings though.
>> >> >>> This is the reason for the behavior you observed below.
>> >> >>>
>> >> >>> In the request you have sent below does not contain enough
>> >> information
>> >> >>> to dispatch it to the correct operation of the service. If you had
>> >> the
>> >> >>> operation name at the end of it it would have worked. And BTW when
>> >> you
>> >> >>> are using service client directly it will not append the operation
>> >> >>> name to the EPR. Note that you have to configure the ServiceClient
>> >> >>> your self when using this. (This is not the case for stubs
>> generated
>> >> >>> for the httpBinding though).
>> >> >>>
>> >> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
>> >> >>> <ni...@imperial.ac.uk> wrote:
>> >> >>>>
>> >> >>>> Thank you Jay and Keith for your replies. I've upgraded to
>> version
>> >> >>>> 1.4.1
>> >> >>>> but
>> >> >>>> this had made no difference. Below is a really simple version of
>> my
>> >> >>>> code
>> >> >>>> taking the options used by Jay in his working service but I can
>> >> still
>> >> >>>> only
>> >> >>>> get the correct response using getGigsIn() with POST, every other
>> >> >>>> combination else fails with:
>> >> >>>> <soapenv:Reason
>> >> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>> >> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference
>> (EPR)
>> >> for
>> >> >>>> the
>> >> >>>> Operation not found is
>> >> /NicksGigs-war-Axis2/services/GigListingsService
>> >> >>>> and
>> >> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>> >> >>>>
>> >> >>>> SimpleREST.java:
>> >> >>>> String epr =
>> >> >>>> "
>> >>
>> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>> >> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>> >> >>>> Options options = portal._getServiceClient().getOptions();
>> >> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> >> Boolean.TRUE);
>> >> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >> >>>> Constants.Configuration.HTTP_METHOD_POST);
>> >> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>> >> >>>>
>> >>
>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>> >> >>>>
>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>> >> >>>> Constants.VALUE_TRUE);
>> >> >>>> options.setCallTransportCleanup(true);
>> >> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>> >> >>>> portal._getServiceClient().setOptions(options);
>> >> >>>> Gig[] results = portal.getGigsIn("London");
>> >> >>>> for (int j = 0; j < results.length; j++)
>> >> >>>> System.out.println(results[j].getToString());
>> >> >>>>
>> >> >>>> Note that I had to comment out the MESSAGE_TYPE property for this
>> to
>> >> >>>> work. I
>> >> >>>> have also commented out the SOAP_ACTION property here since
>> although
>> >> it
>> >> >>>> did
>> >> >>>> remove the action(s) in the header it didn't make any difference
>> to
>> >> the
>> >> >>>> end
>> >> >>>> result.
>> >> >>>>
>> >> >>>> The thing which strikes me most about this is that whether using
>> GET
>> >> or
>> >> >>>> POST
>> >> >>>> the bindings do not append the method names to the endpoint like
>> I
>> >> >>>> would
>> >> >>>> expect them to. I wrongly assumed that at some point the axis
>> >> >>>> generated
>> >> >>>> code would do something like endpoint+"/"+methodName but it
>> doesn't
>> >> >>>> seem
>> >> >>>> to... Is this correct behaviour?
>> >> >>>>
>> >> >>>> I took a look at the blog entry and after a closer look at my
>> WSDL
>> >> it
>> >> >>>> seems
>> >> >>>> that the one generated at
>> >> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the
>> >> correct
>> >> >>>> parameter names, but the wsdl generated by the maven java2wsdl
>> >> plugin
>> >> >>>> and
>> >> >>>> then subsequently used by wsdl2java to create my stub has the
>> >> param0,
>> >> >>>> param1
>> >> >>>> names. Maven automatically compiles with debug on and I've made
>> no
>> >> >>>> changes
>> >> >>>> to this so I am a bit confused why I'm getting this. Even more so
>> by
>> >> >>>> the
>> >> >>>> fact that if I create unwrapped bindings then the correct
>> parameter
>> >> >>>> names
>> >> >>>> are used.
>> >> >>>
>> >> >>> This is strange. I haven't tried this out though (wsdl2java maven
>> >> >>> plugin). Would give it a try and let you know.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Keith.
>> >> >>>>
>> >> >>>> Thanks
>> >> >>>> Nick
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> keith chapman wrote:
>> >> >>>>>
>> >> >>>>> Hi Nick,
>> >> >>>>>
>> >> >>>>> Sorry I couldn't get back to you sooner. Was held up with some
>> >> travel
>> >> >>>>> last week. So here goes, see my comments inline. (As a summary
>> >> could
>> >> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this
>> >> release)
>> >> >>>>>
>> >> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>> >> >>>>> <ni...@imperial.ac.uk> wrote:
>> >> >>>>>>
>> >> >>>>>> Hi,
>> >> >>>>>>
>> >> >>>>>> I've recently started looking at using the REST support in
>> Axis2
>> >> to
>> >> >>>>>> invoke
>> >> >>>>>> my web service instead of the currently used SOAP calls and I
>> have
>> >> a
>> >> >>>>>> number
>> >> >>>>>> of issues I can't work out for myself. Any help with these
>> would
>> >> be
>> >> >>>>>> great.
>> >> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in
>> the
>> >> >>>>>> hope
>> >> >>>>>> my
>> >> >>>>>> issues would be solved) and tcpmon to monitor the traffic
>> between
>> >> my
>> >> >>>>>> test
>> >> >>>>>> client and my service running locally on tomcat at
>> >> >
>> >> >>>>>>
>> >> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>> >> >>>>>> The
>> >> >>>>>> WSDL is created using java2wsdl and is attached.
>> >> >>>>>>
>> >> >>>>>> I've read in another (old) post here that Axis2 is just a soap
>> >> stack
>> >> >>>>>> and
>> >> >>>>>> any
>> >> >>>>>> incoming rest style messages are converted into soap messages
>> >> first
>> >> >>>>>> so
>> >> >>>>>> that
>> >> >>>>>> they can then be processed. Is this still the case?
>> >> >>>>>
>> >> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message
>> gets
>> >> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>> >> >>>>> message we do create a SOAP message out of it.
>> >> >>>>>
>> >> >>>>> Does this have a
>> >> >>>>>> performance hit? Is there anything in the documentation about
>> >> this?
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for
>> my
>> >> test
>> >> >>>>>> client, to use the rest style web calls with the bindings is it
>> >> >>>>>> simply
>> >> >>>>>> a
>> >> >>>>>> case of adding the line of code below into my client?
>> >> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> >> >>>>>> Constants.VALUE_TRUE);
>> >> >>>>>> I want to clarify this since all the examples I have seen do
>> not
>> >> use
>> >> >>>>>> bindings.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> Is it possible to use both POST and GET when my operation
>> >> parameters
>> >> >>>>>> are
>> >> >>>>>> all
>> >> >>>>>> simple types? To change between the two transports is it
>> simply
>> a
>> >> >>>>>> case
>> >> >>>>>> of
>> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >> >>>>>> HTTP_METHOD_GET);
>> >> >>>>>> Or
>> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >> >>>>>> HTTP_METHOD_POST);
>> >> >>>>>> ?
>> >> >>>>>
>> >> >>>>> Yes you could set the HTTP Method you need as explained above.
>> >> Axis2
>> >> >>>>> also supports PUT and DELETE.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> I've found that I can use POST with operations that have
>> >> parameters
>> >> >>>>>> but
>> >> >>>>>> not
>> >> >>>>>> on those without parameters. For example, a call to
>> >> >>>>>> getGigsIn("London")
>> >> >>>>>> using HTTP_POST makes the following successful request:
>> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> >> >>>>>> Content-Type: application/xml; charset=UTF-8
>> >> >>>>>> SOAPAction: urn:getGigsIn
>> >> >>>>>> User-Agent: Axis2
>> >> >>>>>> Content-Length: 115
>> >> >>>>>>
>> >> >>>>>> <ns2:getGigsIn
>> >> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
>> >> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>> >> >>>>>>
>> >> >>>>>> But a call to getMostActiveArtist() makes the following
>> >> unsuccessful
>> >> >>>>>> request:
>> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> >> >>>>>> Content-Type: application/xml; charset=UTF-8
>> >> >>>>>> SOAPAction: urn:getMostActiveArtist
>> >> >>>>>> User-Agent: Axis2
>> >> >>>>>> Content-Length: 0
>> >> >>>>>>
>> >> >>>>>> with received error:
>> >> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation not
>> >> found
>> >> >>>>>> is
>> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>> >> Action
>> >> =
>> >> >>>>>> null</faultstring>
>> >> >>>>>>
>> >> >>>>>> Why doesn't this work??
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make
>> any
>> >> >>>>>> successful
>> >> >>>>>> calls to my service. getGigsIn("London") gives:
>> >> >>>>>> GET
>> /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>> >> >>>>>> HTTP/1.1
>> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>> >> >>>>>> SOAPAction: urn:getGigsIn
>> >> >>>>>> User-Agent: Axis2
>> >> >>>>>>
>> >> >>>>>> <soapenv:Reason
>> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>> >> "><soapenv:Text
>> >> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation
>> >> not
>> >> >>>>>> found
>> >> >>>>>> is
>> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>> >> Action
>> >> =
>> >> >>>>>> null</soapenv:Text></soapenv:Reason>
>> >> >>>>>>
>> >> >>>>>> while getMostActiveArtist() gives:
>> >> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>> >> >>>>>> SOAPAction: urn:getMostActiveArtist
>> >> >>>>>> User-Agent: Axis2
>> >> >>>>>>
>> >> >>>>>> And the same error response.
>> >> >>>>>>
>> >> >>>>>> Shouldn't the bindings be appending the operation name onto the
>> >> end
>> >> >>>>>> of
>> >> >>>>>> the
>> >> >>>>>> endpoint for me? If I explicitly set the endpoint to
>> >> >>>>>>
>> >>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>> >> >>>>>> it makes the following request:
>> >> >>>>>> GET
>> >> >>>>>>
>> >>
>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>> >> >>>>>> HTTP/1.1
>> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>> >> >>>>>> SOAPAction: urn:getGigsIn
>> >> >>>>>> User-Agent: Axis2
>> >> >>>>>>
>> >> >>>>>> Which still gives an error, but this time:
>> >> >>>>>> <soapenv:Reason
>> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>> >> "><soapenv:Text
>> >> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke
>> service
>> >> >>>>>> method
>> >> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>> >> >>>>>>
>> >> >>>>>> If I simply go to
>> >> >>>>>>
>> >>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>> >> >>>>>> in my browser I get the correct response.
>> >> >>>>>
>> >> >>>>> The above should work for you correctly with codegenerated
>> stubs.
>> >> Can
>> >> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
>> >> >>>>> invocation for this release and verified that these stuff work.
>> >> >>>>>>
>> >> >>>>>> For me, one of the advantages of the generated bindings is not
>> >> having
>> >> >>>>>> to
>> >> >>>>>> worry about the contents of the WSDL; I shouldn't have to know
>> >> that
>> >> >>>>>> the
>> >> >>>>>> WSDL
>> >> >>>>>> says I must specify the "city" parameter in my query string for
>> >> the
>> >> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
>> >> >>>>>> instead?
>> >> >>>>>
>> >> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you
>> the
>> >> >>>>> answer to this.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> Finally, the documentation specifies that Axis2 determines if
>> an
>> >> >>>>>> incoming
>> >> >>>>>> message is REST or SOAP by checking if "the content type is
>> >> text/xml
>> >> >>>>>> and
>> >> >>>>>> if
>> >> >>>>>> the SOAPAction Header is missing". If you examine the requests
>> >> the
>> >> >>>>>> following headers are present for each method.
>> >> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>> >> >>>>>> HTTP_POST: Just SOAPAction
>> >> >>>>>> SOAP: Just "action" in Content-Type
>> >> >>>>>>
>> >> >>>>>> What is going on here, are these the correct headers? And what
>> is
>> >> the
>> >> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>> >> >>>>>> Content-Type!?
>> >> >>>>>> I also found that when using POST I can even remove the
>> SOAPAction
>> >> >>>>>> header
>> >> >>>>>> but providing I ensure the Content-Type still contains
>> >> >>>>>> "application/xml"
>> >> >>>>>> I
>> >> >>>>>> will still receive the correct (non-soap) response from the
>> >> service.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> I'm aware I might be doing something fundamentally wrong on the
>> >> >>>>>> client
>> >> >>>>>> side
>> >> >>>>>> (maybe you can't use ADB bindings?) to get these results and
>> I'd
>> >> be
>> >> >>>>>> very
>> >> >>>>>> grateful for any responses to any of these questions.
>> >> >>>>>
>> >> >>>>> You can use codegenerated stub to invoke REST services.
>> >> >>>>>
>> >> >>>>> Thanks,
>> >> >>>>> Keith.
>> >> >>>>>>
>> >> >>>>>> Thanks,
>> >> >>>>>> Nick
>> >> >>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>> >> >>>>>> --
>> >> >>>>>> View this message in context:
>> >> >>>>>>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>> >> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> Keith Chapman
>> >> >>>>> Senior Software Engineer
>> >> >>>>> WSO2 Inc.
>> >> >>>>> Oxygenating the Web Service Platform.
>> >> >>>>> http://wso2.org/
>> >> >>>>>
>> >> >>>>> blog: http://www.keith-chapman.org
>> >> >>>>>
>> >> >>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> View this message in context:
>> >> >>>>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>> >> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Keith Chapman
>> >> >>> Senior Software Engineer
>> >> >>> WSO2 Inc.
>> >> >>> Oxygenating the Web Service Platform.
>> >> >>> http://wso2.org/
>> >> >>>
>> >> >>> blog: http://www.keith-chapman.org
>> >> >>>
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
>> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Keith Chapman
>> >> > Senior Software Engineer
>> >> > WSO2 Inc.
>> >> > Oxygenating the Web Service Platform.
>> >> > http://wso2.org/
>> >> >
>> >> > blog: http://www.keith-chapman.org
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
>> >> Sent from the Axis - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Keith Chapman
>> > Senior Software Engineer
>> > WSO2 Inc.
>> > Oxygenating the Web Service Platform.
>> > http://wso2.org/
>> >
>> > blog: http://www.keith-chapman.org
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19285397.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19288850.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Posted by keith chapman <ke...@gmail.com>.
Hi Nick,
Looking through the WSDLs I don't see any reason for the input/output types
in the stub to go missing when generated off a WSDL 1.1 doc. I may have to
test this to make sure that this is the case though. On the subject of a
particular operation not working when invoked via GET. In a previous mail
you said that " I have now generated the httpbindings using wsdl2java with a
version 2.0 wsdl and the operation has been added to the EPR as desired and
I can do POST getGigsIn("London"), POST getMostActiveArtist() and GET
getMostActiveArtist() without any problems which is great. "
How did you send a GET to getMostActiveArtist()? I assume that you set the
httpmethod on the options object of the serviceClient to GET (cause the stub
will send a POST by default according to the WSDL). Could you please explain
a bit what you did to send that request. I just had a look at the code and
when its a GET or a DELETE we use the application/x-www-form-urlencoded as
the content-type. (BTW which version of axis2 did u use?)
The default WSDL generated by axis2 will have all operations exposed over
POST with the inputSerialization of application/XML. If you need to change
this (expose some operations over GET) you may do so by hand editing the
generated WSDL and using that. This may be better cause you choose which
method you want to expose your operations under.
Thanks,
Keith.
On Wed, Sep 3, 2008 at 2:28 PM, Nick Steel
<ni...@imperial.ac.uk>wrote:
>
> Keith,
>
> Please find both versions of my wsdl attached. Note that these are the
> files generated using Maven java2wsdl at buildtime that I then go on to use
> with Maven wsdl2java to get my client stubs.
> http://www.nabble.com/file/p19285397/NicksGigs.wsdl NicksGigs.wsdl
> http://www.nabble.com/file/p19285397/NicksGigsV2.wsdl NicksGigsV2.wsdl
>
> Ad you can see my wsdl doesn't contain any inputSerialization fields at
> all.
> And the method seems to be POST be default, is this the problem?
>
> Nick
>
>
> keith chapman wrote:
> >
> > Hi Nick,
> >
> > See My comments inline
> >
> > On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel
> > <nicholas.steel05@imperial.ac.uk
> >> wrote:
> >
> >>
> >> I have now generated the httpbindings using wsdl2java with a version 2.0
> >> wsdl
> >> and the operation has been added to the EPR as desired and I can do POST
> >> getGigsIn("London"), POST getMostActiveArtist() and GET
> >> getMostActiveArtist() without any problems which is great.
> >
> >
> > Cool, thats good news.
> >
> >
> >> The headers for
> >> both GET and POST are also now the same (see below) which makes a lot
> >> more
> >> sense to me.
> >> Content-Type: application/xml; charset=UTF-8
> >> SOAPAction: ""
> >>
> >
> > I've already opened a JIRA against axis2 for the above. The client should
> > not sent the SOAP action when it is a REST request. Will fix this soon
> >
> >
> >>
> >>
> >>
> >> However, when I try to do GET getGigsIn("London") I get the error
> >> <faultstring>unknown</faultstring>. The request according to TCPmon is:
> >> GET
> >>
> >>
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
> >> HTTP/1.1
> >> Content-Type: application/xml; charset=UTF-8
> >> SOAPAction: ""
> >> User-Agent: Axis2
> >> Host: 10.4.39.241:8089
> >
> >
> > Something is obviously wrong here. You cannot send a GET using
> > application/xml. A get should always be
> application/x-www-form-urlencoded.
> > Can yu check your WSDL2 section for this operation please. Does it say
> > what
> > its inputSerialization is?
> >
> >
> >> <http://10.4.39.241:8089>
> >>
> >> The operation is there in the URL but the parameter "London" is not so
> >> it's
> >> obviously not going to work. I was expecting something more like
> >> GET
> >>
> >>
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
> >> HTTP/1.1
> >>
> >> Whats going wrong here?
> >
> >
> > Just answered above ;).
> >
> >>
> >>
> >> Also, just to see what would happen, I tried to make some httpbindings
> >> using
> >> a version 1.1 wsdl but the generated stub had methods like void
> >> getGigsIn()
> >> and void getMostActiveArtist() which don't take or return any values so
> I
> >> couldn't work out how I could possibly use them. Is this normal or is
> >> this
> >> the reason you said to use a version 2.0 wsdl?httpBinding.
> >>
> >
> > WSDL 2.0 has a much richer That is the reason I recommended you to use
> > that.
> > But ?wsdl should have worked as well, we map the properties of ?wsdl to
> > the
> > ones of ?wsdl2 during code generation. Is it possible for you to share
> > your
> > wsdl and wsdl2 as well.
> >
> > Thanks,
> > Keith.
> >
> >
> >>
> >>
> >> Cheers,
> >> Nick
> >>
> >>
> >> keith chapman wrote:
> >> >
> >> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
> >> > <ni...@imperial.ac.uk> wrote:
> >> >>
> >> >> Keith,
> >> >>
> >> >> I had no idea ?wsdl2 even existed,
> >> >
> >> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
> >> > HTTPBinding can describe a REST interface for your service in a nice
> >> > manner.
> >> >
> >> > I've no idea how I managed to miss this
> >> >> but I will hunt for it tomorrow and give it a go. Thanks very much
> >> this
> >> >> reply, what you say aout the EPR has definitely cleared some things
> up
> >> >> for
> >> >> me and hopefully I can now go on to get this to work.
> >> >>
> >> >> Just to be clear though, you say I should generate the client stub
> for
> >> >> the
> >> >> httpbinding, how exactly do I do this? I thought the stub I already
> >> had
> >> >> could handle all the bindings in my wsdl and that setting the portal
> >> >> parameters was what controlled which binding was being used. Is this
> >> >> wrong?
> >> >
> >> > When codegeneration is used to generate the server side code its only
> >> > the portType (or the interface if WSDL 2.0) that we care about when
> >> > generating code. But when its generating code for the client side we
> >> > generate it for a particular port and you can specify this by using
> >> > the -pn option. If a port if not provided it faults to use the first
> >> > SOAP 1.2 port it finds. You could generate code for all ports too this
> >> > can be done by using the -ap options. This will generate stubs for all
> >> > ports in the WSDL. So for example if I take the same RESTSample that I
> >> > used yesterday this is how I would generate code for its HTTPBinding.
> >> >
> >> > wsdl2java.sh -uri
> http://mooshup.com/services/samples/RESTSample?wsdl2
> >> > -pn HTTPEndpoint -wv 2
> >> >
> >> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
> >> >
> >> > Thanks,
> >> > Keith.
> >> >>
> >> >> Cheers,
> >> >> Nick
> >> >>
> >> >>
> >> >> keith chapman wrote:
> >> >>>
> >> >>> Hi Nick,
> >> >>>
> >> >>> If you want to invoke a service using REST then its better to
> >> generate
> >> >>> the client stub for the httpBinding (and when doing so I recommend
> >> you
> >> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
> >> >>> interface of the service. This is where it will contain details of
> >> the
> >> >>> URL the operation is available at hence if this binding is used to
> >> >>> invoke the service it will automatically add the operation name to
> >> the
> >> >>> end of the EPR. This does not happen for the SOAP bindings though.
> >> >>> This is the reason for the behavior you observed below.
> >> >>>
> >> >>> In the request you have sent below does not contain enough
> >> information
> >> >>> to dispatch it to the correct operation of the service. If you had
> >> the
> >> >>> operation name at the end of it it would have worked. And BTW when
> >> you
> >> >>> are using service client directly it will not append the operation
> >> >>> name to the EPR. Note that you have to configure the ServiceClient
> >> >>> your self when using this. (This is not the case for stubs generated
> >> >>> for the httpBinding though).
> >> >>>
> >> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
> >> >>> <ni...@imperial.ac.uk> wrote:
> >> >>>>
> >> >>>> Thank you Jay and Keith for your replies. I've upgraded to version
> >> >>>> 1.4.1
> >> >>>> but
> >> >>>> this had made no difference. Below is a really simple version of
> my
> >> >>>> code
> >> >>>> taking the options used by Jay in his working service but I can
> >> still
> >> >>>> only
> >> >>>> get the correct response using getGigsIn() with POST, every other
> >> >>>> combination else fails with:
> >> >>>> <soapenv:Reason
> >> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> >> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR)
> >> for
> >> >>>> the
> >> >>>> Operation not found is
> >> /NicksGigs-war-Axis2/services/GigListingsService
> >> >>>> and
> >> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
> >> >>>>
> >> >>>> SimpleREST.java:
> >> >>>> String epr =
> >> >>>> "
> >> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
> >> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
> >> >>>> Options options = portal._getServiceClient().getOptions();
> >> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> >> Boolean.TRUE);
> >> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >> >>>> Constants.Configuration.HTTP_METHOD_POST);
> >> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
> >> >>>>
> >> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
> >> >>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
> >> >>>> Constants.VALUE_TRUE);
> >> >>>> options.setCallTransportCleanup(true);
> >> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
> >> >>>> portal._getServiceClient().setOptions(options);
> >> >>>> Gig[] results = portal.getGigsIn("London");
> >> >>>> for (int j = 0; j < results.length; j++)
> >> >>>> System.out.println(results[j].getToString());
> >> >>>>
> >> >>>> Note that I had to comment out the MESSAGE_TYPE property for this
> to
> >> >>>> work. I
> >> >>>> have also commented out the SOAP_ACTION property here since
> although
> >> it
> >> >>>> did
> >> >>>> remove the action(s) in the header it didn't make any difference to
> >> the
> >> >>>> end
> >> >>>> result.
> >> >>>>
> >> >>>> The thing which strikes me most about this is that whether using
> GET
> >> or
> >> >>>> POST
> >> >>>> the bindings do not append the method names to the endpoint like I
> >> >>>> would
> >> >>>> expect them to. I wrongly assumed that at some point the axis
> >> >>>> generated
> >> >>>> code would do something like endpoint+"/"+methodName but it doesn't
> >> >>>> seem
> >> >>>> to... Is this correct behaviour?
> >> >>>>
> >> >>>> I took a look at the blog entry and after a closer look at my WSDL
> >> it
> >> >>>> seems
> >> >>>> that the one generated at
> >> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the
> >> correct
> >> >>>> parameter names, but the wsdl generated by the maven java2wsdl
> >> plugin
> >> >>>> and
> >> >>>> then subsequently used by wsdl2java to create my stub has the
> >> param0,
> >> >>>> param1
> >> >>>> names. Maven automatically compiles with debug on and I've made no
> >> >>>> changes
> >> >>>> to this so I am a bit confused why I'm getting this. Even more so
> by
> >> >>>> the
> >> >>>> fact that if I create unwrapped bindings then the correct parameter
> >> >>>> names
> >> >>>> are used.
> >> >>>
> >> >>> This is strange. I haven't tried this out though (wsdl2java maven
> >> >>> plugin). Would give it a try and let you know.
> >> >>>
> >> >>> Thanks,
> >> >>> Keith.
> >> >>>>
> >> >>>> Thanks
> >> >>>> Nick
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> keith chapman wrote:
> >> >>>>>
> >> >>>>> Hi Nick,
> >> >>>>>
> >> >>>>> Sorry I couldn't get back to you sooner. Was held up with some
> >> travel
> >> >>>>> last week. So here goes, see my comments inline. (As a summary
> >> could
> >> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this
> >> release)
> >> >>>>>
> >> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
> >> >>>>> <ni...@imperial.ac.uk> wrote:
> >> >>>>>>
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> I've recently started looking at using the REST support in Axis2
> >> to
> >> >>>>>> invoke
> >> >>>>>> my web service instead of the currently used SOAP calls and I
> have
> >> a
> >> >>>>>> number
> >> >>>>>> of issues I can't work out for myself. Any help with these would
> >> be
> >> >>>>>> great.
> >> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the
> >> >>>>>> hope
> >> >>>>>> my
> >> >>>>>> issues would be solved) and tcpmon to monitor the traffic between
> >> my
> >> >>>>>> test
> >> >>>>>> client and my service running locally on tomcat at
> >> >
> >> >>>>>>
> >> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
> >> >>>>>> The
> >> >>>>>> WSDL is created using java2wsdl and is attached.
> >> >>>>>>
> >> >>>>>> I've read in another (old) post here that Axis2 is just a soap
> >> stack
> >> >>>>>> and
> >> >>>>>> any
> >> >>>>>> incoming rest style messages are converted into soap messages
> >> first
> >> >>>>>> so
> >> >>>>>> that
> >> >>>>>> they can then be processed. Is this still the case?
> >> >>>>>
> >> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message
> gets
> >> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
> >> >>>>> message we do create a SOAP message out of it.
> >> >>>>>
> >> >>>>> Does this have a
> >> >>>>>> performance hit? Is there anything in the documentation about
> >> this?
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my
> >> test
> >> >>>>>> client, to use the rest style web calls with the bindings is it
> >> >>>>>> simply
> >> >>>>>> a
> >> >>>>>> case of adding the line of code below into my client?
> >> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> >> >>>>>> Constants.VALUE_TRUE);
> >> >>>>>> I want to clarify this since all the examples I have seen do not
> >> use
> >> >>>>>> bindings.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Is it possible to use both POST and GET when my operation
> >> parameters
> >> >>>>>> are
> >> >>>>>> all
> >> >>>>>> simple types? To change between the two transports is it simply
> a
> >> >>>>>> case
> >> >>>>>> of
> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >> >>>>>> HTTP_METHOD_GET);
> >> >>>>>> Or
> >> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >> >>>>>> HTTP_METHOD_POST);
> >> >>>>>> ?
> >> >>>>>
> >> >>>>> Yes you could set the HTTP Method you need as explained above.
> >> Axis2
> >> >>>>> also supports PUT and DELETE.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> I've found that I can use POST with operations that have
> >> parameters
> >> >>>>>> but
> >> >>>>>> not
> >> >>>>>> on those without parameters. For example, a call to
> >> >>>>>> getGigsIn("London")
> >> >>>>>> using HTTP_POST makes the following successful request:
> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >> >>>>>> Content-Type: application/xml; charset=UTF-8
> >> >>>>>> SOAPAction: urn:getGigsIn
> >> >>>>>> User-Agent: Axis2
> >> >>>>>> Content-Length: 115
> >> >>>>>>
> >> >>>>>> <ns2:getGigsIn
> >> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
> >> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
> >> >>>>>>
> >> >>>>>> But a call to getMostActiveArtist() makes the following
> >> unsuccessful
> >> >>>>>> request:
> >> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >> >>>>>> Content-Type: application/xml; charset=UTF-8
> >> >>>>>> SOAPAction: urn:getMostActiveArtist
> >> >>>>>> User-Agent: Axis2
> >> >>>>>> Content-Length: 0
> >> >>>>>>
> >> >>>>>> with received error:
> >> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation not
> >> found
> >> >>>>>> is
> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
> >> Action
> >> =
> >> >>>>>> null</faultstring>
> >> >>>>>>
> >> >>>>>> Why doesn't this work??
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
> >> >>>>>> successful
> >> >>>>>> calls to my service. getGigsIn("London") gives:
> >> >>>>>> GET
> /NicksGigs-war-Axis2/services/GigListingsService?param0=London
> >> >>>>>> HTTP/1.1
> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >> >>>>>> SOAPAction: urn:getGigsIn
> >> >>>>>> User-Agent: Axis2
> >> >>>>>>
> >> >>>>>> <soapenv:Reason
> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
> >> "><soapenv:Text
> >> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation
> >> not
> >> >>>>>> found
> >> >>>>>> is
> >> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
> >> Action
> >> =
> >> >>>>>> null</soapenv:Text></soapenv:Reason>
> >> >>>>>>
> >> >>>>>> while getMostActiveArtist() gives:
> >> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
> >> >>>>>> SOAPAction: urn:getMostActiveArtist
> >> >>>>>> User-Agent: Axis2
> >> >>>>>>
> >> >>>>>> And the same error response.
> >> >>>>>>
> >> >>>>>> Shouldn't the bindings be appending the operation name onto the
> >> end
> >> >>>>>> of
> >> >>>>>> the
> >> >>>>>> endpoint for me? If I explicitly set the endpoint to
> >> >>>>>>
> >>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
> >> >>>>>> it makes the following request:
> >> >>>>>> GET
> >> >>>>>>
> >> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
> >> >>>>>> HTTP/1.1
> >> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >> >>>>>> SOAPAction: urn:getGigsIn
> >> >>>>>> User-Agent: Axis2
> >> >>>>>>
> >> >>>>>> Which still gives an error, but this time:
> >> >>>>>> <soapenv:Reason
> >> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
> >> "><soapenv:Text
> >> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke
> service
> >> >>>>>> method
> >> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
> >> >>>>>>
> >> >>>>>> If I simply go to
> >> >>>>>>
> >>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
> >> >>>>>> in my browser I get the correct response.
> >> >>>>>
> >> >>>>> The above should work for you correctly with codegenerated stubs.
> >> Can
> >> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
> >> >>>>> invocation for this release and verified that these stuff work.
> >> >>>>>>
> >> >>>>>> For me, one of the advantages of the generated bindings is not
> >> having
> >> >>>>>> to
> >> >>>>>> worry about the contents of the WSDL; I shouldn't have to know
> >> that
> >> >>>>>> the
> >> >>>>>> WSDL
> >> >>>>>> says I must specify the "city" parameter in my query string for
> >> the
> >> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
> >> >>>>>> instead?
> >> >>>>>
> >> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
> >> >>>>> answer to this.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Finally, the documentation specifies that Axis2 determines if an
> >> >>>>>> incoming
> >> >>>>>> message is REST or SOAP by checking if "the content type is
> >> text/xml
> >> >>>>>> and
> >> >>>>>> if
> >> >>>>>> the SOAPAction Header is missing". If you examine the requests
> >> the
> >> >>>>>> following headers are present for each method.
> >> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
> >> >>>>>> HTTP_POST: Just SOAPAction
> >> >>>>>> SOAP: Just "action" in Content-Type
> >> >>>>>>
> >> >>>>>> What is going on here, are these the correct headers? And what is
> >> the
> >> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
> >> >>>>>> Content-Type!?
> >> >>>>>> I also found that when using POST I can even remove the
> SOAPAction
> >> >>>>>> header
> >> >>>>>> but providing I ensure the Content-Type still contains
> >> >>>>>> "application/xml"
> >> >>>>>> I
> >> >>>>>> will still receive the correct (non-soap) response from the
> >> service.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> I'm aware I might be doing something fundamentally wrong on the
> >> >>>>>> client
> >> >>>>>> side
> >> >>>>>> (maybe you can't use ADB bindings?) to get these results and I'd
> >> be
> >> >>>>>> very
> >> >>>>>> grateful for any responses to any of these questions.
> >> >>>>>
> >> >>>>> You can use codegenerated stub to invoke REST services.
> >> >>>>>
> >> >>>>> Thanks,
> >> >>>>> Keith.
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>> Nick
> >> >>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
> >> >>>>>> --
> >> >>>>>> View this message in context:
> >> >>>>>>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
> >> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> Keith Chapman
> >> >>>>> Senior Software Engineer
> >> >>>>> WSO2 Inc.
> >> >>>>> Oxygenating the Web Service Platform.
> >> >>>>> http://wso2.org/
> >> >>>>>
> >> >>>>> blog: http://www.keith-chapman.org
> >> >>>>>
> >> >>>>>
> >> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>> --
> >> >>>> View this message in context:
> >> >>>>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
> >> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >>>>
> >> >>>>
> >> >>>>
> >> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Keith Chapman
> >> >>> Senior Software Engineer
> >> >>> WSO2 Inc.
> >> >>> Oxygenating the Web Service Platform.
> >> >>> http://wso2.org/
> >> >>>
> >> >>> blog: http://www.keith-chapman.org
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
> >> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Keith Chapman
> >> > Senior Software Engineer
> >> > WSO2 Inc.
> >> > Oxygenating the Web Service Platform.
> >> > http://wso2.org/
> >> >
> >> > blog: http://www.keith-chapman.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> > Keith Chapman
> > Senior Software Engineer
> > WSO2 Inc.
> > Oxygenating the Web Service Platform.
> > http://wso2.org/
> >
> > blog: http://www.keith-chapman.org
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19285397.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
Keith,
Please find both versions of my wsdl attached. Note that these are the
files generated using Maven java2wsdl at buildtime that I then go on to use
with Maven wsdl2java to get my client stubs.
http://www.nabble.com/file/p19285397/NicksGigs.wsdl NicksGigs.wsdl
http://www.nabble.com/file/p19285397/NicksGigsV2.wsdl NicksGigsV2.wsdl
Ad you can see my wsdl doesn't contain any inputSerialization fields at all.
And the method seems to be POST be default, is this the problem?
Nick
keith chapman wrote:
>
> Hi Nick,
>
> See My comments inline
>
> On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel
> <nicholas.steel05@imperial.ac.uk
>> wrote:
>
>>
>> I have now generated the httpbindings using wsdl2java with a version 2.0
>> wsdl
>> and the operation has been added to the EPR as desired and I can do POST
>> getGigsIn("London"), POST getMostActiveArtist() and GET
>> getMostActiveArtist() without any problems which is great.
>
>
> Cool, thats good news.
>
>
>> The headers for
>> both GET and POST are also now the same (see below) which makes a lot
>> more
>> sense to me.
>> Content-Type: application/xml; charset=UTF-8
>> SOAPAction: ""
>>
>
> I've already opened a JIRA against axis2 for the above. The client should
> not sent the SOAP action when it is a REST request. Will fix this soon
>
>
>>
>>
>>
>> However, when I try to do GET getGigsIn("London") I get the error
>> <faultstring>unknown</faultstring>. The request according to TCPmon is:
>> GET
>>
>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
>> HTTP/1.1
>> Content-Type: application/xml; charset=UTF-8
>> SOAPAction: ""
>> User-Agent: Axis2
>> Host: 10.4.39.241:8089
>
>
> Something is obviously wrong here. You cannot send a GET using
> application/xml. A get should always be application/x-www-form-urlencoded.
> Can yu check your WSDL2 section for this operation please. Does it say
> what
> its inputSerialization is?
>
>
>> <http://10.4.39.241:8089>
>>
>> The operation is there in the URL but the parameter "London" is not so
>> it's
>> obviously not going to work. I was expecting something more like
>> GET
>>
>> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
>> HTTP/1.1
>>
>> Whats going wrong here?
>
>
> Just answered above ;).
>
>>
>>
>> Also, just to see what would happen, I tried to make some httpbindings
>> using
>> a version 1.1 wsdl but the generated stub had methods like void
>> getGigsIn()
>> and void getMostActiveArtist() which don't take or return any values so I
>> couldn't work out how I could possibly use them. Is this normal or is
>> this
>> the reason you said to use a version 2.0 wsdl?httpBinding.
>>
>
> WSDL 2.0 has a much richer That is the reason I recommended you to use
> that.
> But ?wsdl should have worked as well, we map the properties of ?wsdl to
> the
> ones of ?wsdl2 during code generation. Is it possible for you to share
> your
> wsdl and wsdl2 as well.
>
> Thanks,
> Keith.
>
>
>>
>>
>> Cheers,
>> Nick
>>
>>
>> keith chapman wrote:
>> >
>> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
>> > <ni...@imperial.ac.uk> wrote:
>> >>
>> >> Keith,
>> >>
>> >> I had no idea ?wsdl2 even existed,
>> >
>> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
>> > HTTPBinding can describe a REST interface for your service in a nice
>> > manner.
>> >
>> > I've no idea how I managed to miss this
>> >> but I will hunt for it tomorrow and give it a go. Thanks very much
>> this
>> >> reply, what you say aout the EPR has definitely cleared some things up
>> >> for
>> >> me and hopefully I can now go on to get this to work.
>> >>
>> >> Just to be clear though, you say I should generate the client stub for
>> >> the
>> >> httpbinding, how exactly do I do this? I thought the stub I already
>> had
>> >> could handle all the bindings in my wsdl and that setting the portal
>> >> parameters was what controlled which binding was being used. Is this
>> >> wrong?
>> >
>> > When codegeneration is used to generate the server side code its only
>> > the portType (or the interface if WSDL 2.0) that we care about when
>> > generating code. But when its generating code for the client side we
>> > generate it for a particular port and you can specify this by using
>> > the -pn option. If a port if not provided it faults to use the first
>> > SOAP 1.2 port it finds. You could generate code for all ports too this
>> > can be done by using the -ap options. This will generate stubs for all
>> > ports in the WSDL. So for example if I take the same RESTSample that I
>> > used yesterday this is how I would generate code for its HTTPBinding.
>> >
>> > wsdl2java.sh -uri http://mooshup.com/services/samples/RESTSample?wsdl2
>> > -pn HTTPEndpoint -wv 2
>> >
>> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
>> >
>> > Thanks,
>> > Keith.
>> >>
>> >> Cheers,
>> >> Nick
>> >>
>> >>
>> >> keith chapman wrote:
>> >>>
>> >>> Hi Nick,
>> >>>
>> >>> If you want to invoke a service using REST then its better to
>> generate
>> >>> the client stub for the httpBinding (and when doing so I recommend
>> you
>> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
>> >>> interface of the service. This is where it will contain details of
>> the
>> >>> URL the operation is available at hence if this binding is used to
>> >>> invoke the service it will automatically add the operation name to
>> the
>> >>> end of the EPR. This does not happen for the SOAP bindings though.
>> >>> This is the reason for the behavior you observed below.
>> >>>
>> >>> In the request you have sent below does not contain enough
>> information
>> >>> to dispatch it to the correct operation of the service. If you had
>> the
>> >>> operation name at the end of it it would have worked. And BTW when
>> you
>> >>> are using service client directly it will not append the operation
>> >>> name to the EPR. Note that you have to configure the ServiceClient
>> >>> your self when using this. (This is not the case for stubs generated
>> >>> for the httpBinding though).
>> >>>
>> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
>> >>> <ni...@imperial.ac.uk> wrote:
>> >>>>
>> >>>> Thank you Jay and Keith for your replies. I've upgraded to version
>> >>>> 1.4.1
>> >>>> but
>> >>>> this had made no difference. Below is a really simple version of my
>> >>>> code
>> >>>> taking the options used by Jay in his working service but I can
>> still
>> >>>> only
>> >>>> get the correct response using getGigsIn() with POST, every other
>> >>>> combination else fails with:
>> >>>> <soapenv:Reason
>> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR)
>> for
>> >>>> the
>> >>>> Operation not found is
>> /NicksGigs-war-Axis2/services/GigListingsService
>> >>>> and
>> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>> >>>>
>> >>>> SimpleREST.java:
>> >>>> String epr =
>> >>>> "
>> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>> >>>> Options options = portal._getServiceClient().getOptions();
>> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> Boolean.TRUE);
>> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >>>> Constants.Configuration.HTTP_METHOD_POST);
>> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>> >>>>
>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>> >>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>> >>>> Constants.VALUE_TRUE);
>> >>>> options.setCallTransportCleanup(true);
>> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>> >>>> portal._getServiceClient().setOptions(options);
>> >>>> Gig[] results = portal.getGigsIn("London");
>> >>>> for (int j = 0; j < results.length; j++)
>> >>>> System.out.println(results[j].getToString());
>> >>>>
>> >>>> Note that I had to comment out the MESSAGE_TYPE property for this to
>> >>>> work. I
>> >>>> have also commented out the SOAP_ACTION property here since although
>> it
>> >>>> did
>> >>>> remove the action(s) in the header it didn't make any difference to
>> the
>> >>>> end
>> >>>> result.
>> >>>>
>> >>>> The thing which strikes me most about this is that whether using GET
>> or
>> >>>> POST
>> >>>> the bindings do not append the method names to the endpoint like I
>> >>>> would
>> >>>> expect them to. I wrongly assumed that at some point the axis
>> >>>> generated
>> >>>> code would do something like endpoint+"/"+methodName but it doesn't
>> >>>> seem
>> >>>> to... Is this correct behaviour?
>> >>>>
>> >>>> I took a look at the blog entry and after a closer look at my WSDL
>> it
>> >>>> seems
>> >>>> that the one generated at
>> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the
>> correct
>> >>>> parameter names, but the wsdl generated by the maven java2wsdl
>> plugin
>> >>>> and
>> >>>> then subsequently used by wsdl2java to create my stub has the
>> param0,
>> >>>> param1
>> >>>> names. Maven automatically compiles with debug on and I've made no
>> >>>> changes
>> >>>> to this so I am a bit confused why I'm getting this. Even more so by
>> >>>> the
>> >>>> fact that if I create unwrapped bindings then the correct parameter
>> >>>> names
>> >>>> are used.
>> >>>
>> >>> This is strange. I haven't tried this out though (wsdl2java maven
>> >>> plugin). Would give it a try and let you know.
>> >>>
>> >>> Thanks,
>> >>> Keith.
>> >>>>
>> >>>> Thanks
>> >>>> Nick
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> keith chapman wrote:
>> >>>>>
>> >>>>> Hi Nick,
>> >>>>>
>> >>>>> Sorry I couldn't get back to you sooner. Was held up with some
>> travel
>> >>>>> last week. So here goes, see my comments inline. (As a summary
>> could
>> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this
>> release)
>> >>>>>
>> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>> >>>>> <ni...@imperial.ac.uk> wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> I've recently started looking at using the REST support in Axis2
>> to
>> >>>>>> invoke
>> >>>>>> my web service instead of the currently used SOAP calls and I have
>> a
>> >>>>>> number
>> >>>>>> of issues I can't work out for myself. Any help with these would
>> be
>> >>>>>> great.
>> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the
>> >>>>>> hope
>> >>>>>> my
>> >>>>>> issues would be solved) and tcpmon to monitor the traffic between
>> my
>> >>>>>> test
>> >>>>>> client and my service running locally on tomcat at
>> >
>> >>>>>>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>> >>>>>> The
>> >>>>>> WSDL is created using java2wsdl and is attached.
>> >>>>>>
>> >>>>>> I've read in another (old) post here that Axis2 is just a soap
>> stack
>> >>>>>> and
>> >>>>>> any
>> >>>>>> incoming rest style messages are converted into soap messages
>> first
>> >>>>>> so
>> >>>>>> that
>> >>>>>> they can then be processed. Is this still the case?
>> >>>>>
>> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
>> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>> >>>>> message we do create a SOAP message out of it.
>> >>>>>
>> >>>>> Does this have a
>> >>>>>> performance hit? Is there anything in the documentation about
>> this?
>> >>>>>>
>> >>>>>>
>> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my
>> test
>> >>>>>> client, to use the rest style web calls with the bindings is it
>> >>>>>> simply
>> >>>>>> a
>> >>>>>> case of adding the line of code below into my client?
>> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> >>>>>> Constants.VALUE_TRUE);
>> >>>>>> I want to clarify this since all the examples I have seen do not
>> use
>> >>>>>> bindings.
>> >>>>>>
>> >>>>>>
>> >>>>>> Is it possible to use both POST and GET when my operation
>> parameters
>> >>>>>> are
>> >>>>>> all
>> >>>>>> simple types? To change between the two transports is it simply a
>> >>>>>> case
>> >>>>>> of
>> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >>>>>> HTTP_METHOD_GET);
>> >>>>>> Or
>> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> >>>>>> HTTP_METHOD_POST);
>> >>>>>> ?
>> >>>>>
>> >>>>> Yes you could set the HTTP Method you need as explained above.
>> Axis2
>> >>>>> also supports PUT and DELETE.
>> >>>>>>
>> >>>>>>
>> >>>>>> I've found that I can use POST with operations that have
>> parameters
>> >>>>>> but
>> >>>>>> not
>> >>>>>> on those without parameters. For example, a call to
>> >>>>>> getGigsIn("London")
>> >>>>>> using HTTP_POST makes the following successful request:
>> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> >>>>>> Content-Type: application/xml; charset=UTF-8
>> >>>>>> SOAPAction: urn:getGigsIn
>> >>>>>> User-Agent: Axis2
>> >>>>>> Content-Length: 115
>> >>>>>>
>> >>>>>> <ns2:getGigsIn
>> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
>> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>> >>>>>>
>> >>>>>> But a call to getMostActiveArtist() makes the following
>> unsuccessful
>> >>>>>> request:
>> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> >>>>>> Content-Type: application/xml; charset=UTF-8
>> >>>>>> SOAPAction: urn:getMostActiveArtist
>> >>>>>> User-Agent: Axis2
>> >>>>>> Content-Length: 0
>> >>>>>>
>> >>>>>> with received error:
>> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation not
>> found
>> >>>>>> is
>> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>> Action
>> =
>> >>>>>> null</faultstring>
>> >>>>>>
>> >>>>>> Why doesn't this work??
>> >>>>>>
>> >>>>>>
>> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
>> >>>>>> successful
>> >>>>>> calls to my service. getGigsIn("London") gives:
>> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>> >>>>>> HTTP/1.1
>> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>> >>>>>> SOAPAction: urn:getGigsIn
>> >>>>>> User-Agent: Axis2
>> >>>>>>
>> >>>>>> <soapenv:Reason
>> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>> "><soapenv:Text
>> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation
>> not
>> >>>>>> found
>> >>>>>> is
>> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA
>> Action
>> =
>> >>>>>> null</soapenv:Text></soapenv:Reason>
>> >>>>>>
>> >>>>>> while getMostActiveArtist() gives:
>> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>> >>>>>> SOAPAction: urn:getMostActiveArtist
>> >>>>>> User-Agent: Axis2
>> >>>>>>
>> >>>>>> And the same error response.
>> >>>>>>
>> >>>>>> Shouldn't the bindings be appending the operation name onto the
>> end
>> >>>>>> of
>> >>>>>> the
>> >>>>>> endpoint for me? If I explicitly set the endpoint to
>> >>>>>>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>> >>>>>> it makes the following request:
>> >>>>>> GET
>> >>>>>>
>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>> >>>>>> HTTP/1.1
>> >>>>>> Content-Type: application/x-www-form-urlencoded;
>> >>>>>> charset=UTF-8;action="urn:getGigsIn";
>> >>>>>> SOAPAction: urn:getGigsIn
>> >>>>>> User-Agent: Axis2
>> >>>>>>
>> >>>>>> Which still gives an error, but this time:
>> >>>>>> <soapenv:Reason
>> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
>> "><soapenv:Text
>> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke service
>> >>>>>> method
>> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>> >>>>>>
>> >>>>>> If I simply go to
>> >>>>>>
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>> >>>>>> in my browser I get the correct response.
>> >>>>>
>> >>>>> The above should work for you correctly with codegenerated stubs.
>> Can
>> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
>> >>>>> invocation for this release and verified that these stuff work.
>> >>>>>>
>> >>>>>> For me, one of the advantages of the generated bindings is not
>> having
>> >>>>>> to
>> >>>>>> worry about the contents of the WSDL; I shouldn't have to know
>> that
>> >>>>>> the
>> >>>>>> WSDL
>> >>>>>> says I must specify the "city" parameter in my query string for
>> the
>> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
>> >>>>>> instead?
>> >>>>>
>> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
>> >>>>> answer to this.
>> >>>>>>
>> >>>>>>
>> >>>>>> Finally, the documentation specifies that Axis2 determines if an
>> >>>>>> incoming
>> >>>>>> message is REST or SOAP by checking if "the content type is
>> text/xml
>> >>>>>> and
>> >>>>>> if
>> >>>>>> the SOAPAction Header is missing". If you examine the requests
>> the
>> >>>>>> following headers are present for each method.
>> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>> >>>>>> HTTP_POST: Just SOAPAction
>> >>>>>> SOAP: Just "action" in Content-Type
>> >>>>>>
>> >>>>>> What is going on here, are these the correct headers? And what is
>> the
>> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>> >>>>>> Content-Type!?
>> >>>>>> I also found that when using POST I can even remove the SOAPAction
>> >>>>>> header
>> >>>>>> but providing I ensure the Content-Type still contains
>> >>>>>> "application/xml"
>> >>>>>> I
>> >>>>>> will still receive the correct (non-soap) response from the
>> service.
>> >>>>>>
>> >>>>>>
>> >>>>>> I'm aware I might be doing something fundamentally wrong on the
>> >>>>>> client
>> >>>>>> side
>> >>>>>> (maybe you can't use ADB bindings?) to get these results and I'd
>> be
>> >>>>>> very
>> >>>>>> grateful for any responses to any of these questions.
>> >>>>>
>> >>>>> You can use codegenerated stub to invoke REST services.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Keith.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Nick
>> >>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>> >>>>>> --
>> >>>>>> View this message in context:
>> >>>>>>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Keith Chapman
>> >>>>> Senior Software Engineer
>> >>>>> WSO2 Inc.
>> >>>>> Oxygenating the Web Service Platform.
>> >>>>> http://wso2.org/
>> >>>>>
>> >>>>> blog: http://www.keith-chapman.org
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> View this message in context:
>> >>>>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
>> >>>>
>> >>>>
>> >>>>
>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Keith Chapman
>> >>> Senior Software Engineer
>> >>> WSO2 Inc.
>> >>> Oxygenating the Web Service Platform.
>> >>> http://wso2.org/
>> >>>
>> >>> blog: http://www.keith-chapman.org
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
>> >> Sent from the Axis - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Keith Chapman
>> > Senior Software Engineer
>> > WSO2 Inc.
>> > Oxygenating the Web Service Platform.
>> > http://wso2.org/
>> >
>> > blog: http://www.keith-chapman.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19285397.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Posted by keith chapman <ke...@gmail.com>.
Hi Nick,
See My comments inline
On Tue, Sep 2, 2008 at 11:10 PM, Nick Steel <nicholas.steel05@imperial.ac.uk
> wrote:
>
> I have now generated the httpbindings using wsdl2java with a version 2.0
> wsdl
> and the operation has been added to the EPR as desired and I can do POST
> getGigsIn("London"), POST getMostActiveArtist() and GET
> getMostActiveArtist() without any problems which is great.
Cool, thats good news.
> The headers for
> both GET and POST are also now the same (see below) which makes a lot more
> sense to me.
> Content-Type: application/xml; charset=UTF-8
> SOAPAction: ""
>
I've already opened a JIRA against axis2 for the above. The client should
not sent the SOAP action when it is a REST request. Will fix this soon
>
>
>
> However, when I try to do GET getGigsIn("London") I get the error
> <faultstring>unknown</faultstring>. The request according to TCPmon is:
> GET
>
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
> HTTP/1.1
> Content-Type: application/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Axis2
> Host: 10.4.39.241:8089
Something is obviously wrong here. You cannot send a GET using
application/xml. A get should always be application/x-www-form-urlencoded.
Can yu check your WSDL2 section for this operation please. Does it say what
its inputSerialization is?
> <http://10.4.39.241:8089>
>
> The operation is there in the URL but the parameter "London" is not so it's
> obviously not going to work. I was expecting something more like
> GET
>
> /NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
> HTTP/1.1
>
> Whats going wrong here?
Just answered above ;).
>
>
> Also, just to see what would happen, I tried to make some httpbindings
> using
> a version 1.1 wsdl but the generated stub had methods like void getGigsIn()
> and void getMostActiveArtist() which don't take or return any values so I
> couldn't work out how I could possibly use them. Is this normal or is this
> the reason you said to use a version 2.0 wsdl?httpBinding.
>
WSDL 2.0 has a much richer That is the reason I recommended you to use that.
But ?wsdl should have worked as well, we map the properties of ?wsdl to the
ones of ?wsdl2 during code generation. Is it possible for you to share your
wsdl and wsdl2 as well.
Thanks,
Keith.
>
>
> Cheers,
> Nick
>
>
> keith chapman wrote:
> >
> > On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
> > <ni...@imperial.ac.uk> wrote:
> >>
> >> Keith,
> >>
> >> I had no idea ?wsdl2 even existed,
> >
> > Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
> > HTTPBinding can describe a REST interface for your service in a nice
> > manner.
> >
> > I've no idea how I managed to miss this
> >> but I will hunt for it tomorrow and give it a go. Thanks very much this
> >> reply, what you say aout the EPR has definitely cleared some things up
> >> for
> >> me and hopefully I can now go on to get this to work.
> >>
> >> Just to be clear though, you say I should generate the client stub for
> >> the
> >> httpbinding, how exactly do I do this? I thought the stub I already had
> >> could handle all the bindings in my wsdl and that setting the portal
> >> parameters was what controlled which binding was being used. Is this
> >> wrong?
> >
> > When codegeneration is used to generate the server side code its only
> > the portType (or the interface if WSDL 2.0) that we care about when
> > generating code. But when its generating code for the client side we
> > generate it for a particular port and you can specify this by using
> > the -pn option. If a port if not provided it faults to use the first
> > SOAP 1.2 port it finds. You could generate code for all ports too this
> > can be done by using the -ap options. This will generate stubs for all
> > ports in the WSDL. So for example if I take the same RESTSample that I
> > used yesterday this is how I would generate code for its HTTPBinding.
> >
> > wsdl2java.sh -uri http://mooshup.com/services/samples/RESTSample?wsdl2
> > -pn HTTPEndpoint -wv 2
> >
> > I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
> >
> > Thanks,
> > Keith.
> >>
> >> Cheers,
> >> Nick
> >>
> >>
> >> keith chapman wrote:
> >>>
> >>> Hi Nick,
> >>>
> >>> If you want to invoke a service using REST then its better to generate
> >>> the client stub for the httpBinding (and when doing so I recommend you
> >>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
> >>> interface of the service. This is where it will contain details of the
> >>> URL the operation is available at hence if this binding is used to
> >>> invoke the service it will automatically add the operation name to the
> >>> end of the EPR. This does not happen for the SOAP bindings though.
> >>> This is the reason for the behavior you observed below.
> >>>
> >>> In the request you have sent below does not contain enough information
> >>> to dispatch it to the correct operation of the service. If you had the
> >>> operation name at the end of it it would have worked. And BTW when you
> >>> are using service client directly it will not append the operation
> >>> name to the EPR. Note that you have to configure the ServiceClient
> >>> your self when using this. (This is not the case for stubs generated
> >>> for the httpBinding though).
> >>>
> >>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
> >>> <ni...@imperial.ac.uk> wrote:
> >>>>
> >>>> Thank you Jay and Keith for your replies. I've upgraded to version
> >>>> 1.4.1
> >>>> but
> >>>> this had made no difference. Below is a really simple version of my
> >>>> code
> >>>> taking the options used by Jay in his working service but I can still
> >>>> only
> >>>> get the correct response using getGigsIn() with POST, every other
> >>>> combination else fails with:
> >>>> <soapenv:Reason
> >>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> >>>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for
> >>>> the
> >>>> Operation not found is
> /NicksGigs-war-Axis2/services/GigListingsService
> >>>> and
> >>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
> >>>>
> >>>> SimpleREST.java:
> >>>> String epr =
> >>>> "
> http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
> >>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
> >>>> Options options = portal._getServiceClient().getOptions();
> >>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> Boolean.TRUE);
> >>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >>>> Constants.Configuration.HTTP_METHOD_POST);
> >>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
> >>>>
> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
> >>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
> >>>> Constants.VALUE_TRUE);
> >>>> options.setCallTransportCleanup(true);
> >>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
> >>>> portal._getServiceClient().setOptions(options);
> >>>> Gig[] results = portal.getGigsIn("London");
> >>>> for (int j = 0; j < results.length; j++)
> >>>> System.out.println(results[j].getToString());
> >>>>
> >>>> Note that I had to comment out the MESSAGE_TYPE property for this to
> >>>> work. I
> >>>> have also commented out the SOAP_ACTION property here since although
> it
> >>>> did
> >>>> remove the action(s) in the header it didn't make any difference to
> the
> >>>> end
> >>>> result.
> >>>>
> >>>> The thing which strikes me most about this is that whether using GET
> or
> >>>> POST
> >>>> the bindings do not append the method names to the endpoint like I
> >>>> would
> >>>> expect them to. I wrongly assumed that at some point the axis
> >>>> generated
> >>>> code would do something like endpoint+"/"+methodName but it doesn't
> >>>> seem
> >>>> to... Is this correct behaviour?
> >>>>
> >>>> I took a look at the blog entry and after a closer look at my WSDL it
> >>>> seems
> >>>> that the one generated at
> >>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the
> correct
> >>>> parameter names, but the wsdl generated by the maven java2wsdl plugin
> >>>> and
> >>>> then subsequently used by wsdl2java to create my stub has the param0,
> >>>> param1
> >>>> names. Maven automatically compiles with debug on and I've made no
> >>>> changes
> >>>> to this so I am a bit confused why I'm getting this. Even more so by
> >>>> the
> >>>> fact that if I create unwrapped bindings then the correct parameter
> >>>> names
> >>>> are used.
> >>>
> >>> This is strange. I haven't tried this out though (wsdl2java maven
> >>> plugin). Would give it a try and let you know.
> >>>
> >>> Thanks,
> >>> Keith.
> >>>>
> >>>> Thanks
> >>>> Nick
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> keith chapman wrote:
> >>>>>
> >>>>> Hi Nick,
> >>>>>
> >>>>> Sorry I couldn't get back to you sooner. Was held up with some travel
> >>>>> last week. So here goes, see my comments inline. (As a summary could
> >>>>> you try this with 1.4.1 as I did fix some REST bugs for this release)
> >>>>>
> >>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
> >>>>> <ni...@imperial.ac.uk> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've recently started looking at using the REST support in Axis2 to
> >>>>>> invoke
> >>>>>> my web service instead of the currently used SOAP calls and I have a
> >>>>>> number
> >>>>>> of issues I can't work out for myself. Any help with these would be
> >>>>>> great.
> >>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the
> >>>>>> hope
> >>>>>> my
> >>>>>> issues would be solved) and tcpmon to monitor the traffic between my
> >>>>>> test
> >>>>>> client and my service running locally on tomcat at
> >
> >>>>>>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
> >>>>>> The
> >>>>>> WSDL is created using java2wsdl and is attached.
> >>>>>>
> >>>>>> I've read in another (old) post here that Axis2 is just a soap stack
> >>>>>> and
> >>>>>> any
> >>>>>> incoming rest style messages are converted into soap messages first
> >>>>>> so
> >>>>>> that
> >>>>>> they can then be processed. Is this still the case?
> >>>>>
> >>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
> >>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
> >>>>> message we do create a SOAP message out of it.
> >>>>>
> >>>>> Does this have a
> >>>>>> performance hit? Is there anything in the documentation about this?
> >>>>>>
> >>>>>>
> >>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my
> test
> >>>>>> client, to use the rest style web calls with the bindings is it
> >>>>>> simply
> >>>>>> a
> >>>>>> case of adding the line of code below into my client?
> >>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
> >>>>>> Constants.VALUE_TRUE);
> >>>>>> I want to clarify this since all the examples I have seen do not use
> >>>>>> bindings.
> >>>>>>
> >>>>>>
> >>>>>> Is it possible to use both POST and GET when my operation parameters
> >>>>>> are
> >>>>>> all
> >>>>>> simple types? To change between the two transports is it simply a
> >>>>>> case
> >>>>>> of
> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >>>>>> HTTP_METHOD_GET);
> >>>>>> Or
> >>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
> >>>>>> HTTP_METHOD_POST);
> >>>>>> ?
> >>>>>
> >>>>> Yes you could set the HTTP Method you need as explained above. Axis2
> >>>>> also supports PUT and DELETE.
> >>>>>>
> >>>>>>
> >>>>>> I've found that I can use POST with operations that have parameters
> >>>>>> but
> >>>>>> not
> >>>>>> on those without parameters. For example, a call to
> >>>>>> getGigsIn("London")
> >>>>>> using HTTP_POST makes the following successful request:
> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >>>>>> Content-Type: application/xml; charset=UTF-8
> >>>>>> SOAPAction: urn:getGigsIn
> >>>>>> User-Agent: Axis2
> >>>>>> Content-Length: 115
> >>>>>>
> >>>>>> <ns2:getGigsIn
> >>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com
> "><ns2:param0>London</ns2:param0></ns2:getGigsIn>
> >>>>>>
> >>>>>> But a call to getMostActiveArtist() makes the following unsuccessful
> >>>>>> request:
> >>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >>>>>> Content-Type: application/xml; charset=UTF-8
> >>>>>> SOAPAction: urn:getMostActiveArtist
> >>>>>> User-Agent: Axis2
> >>>>>> Content-Length: 0
> >>>>>>
> >>>>>> with received error:
> >>>>>> <faultstring>The endpoint reference (EPR) for the Operation not
> found
> >>>>>> is
> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action
> =
> >>>>>> null</faultstring>
> >>>>>>
> >>>>>> Why doesn't this work??
> >>>>>>
> >>>>>>
> >>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
> >>>>>> successful
> >>>>>> calls to my service. getGigsIn("London") gives:
> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
> >>>>>> HTTP/1.1
> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >>>>>> SOAPAction: urn:getGigsIn
> >>>>>> User-Agent: Axis2
> >>>>>>
> >>>>>> <soapenv:Reason
> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
> "><soapenv:Text
> >>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not
> >>>>>> found
> >>>>>> is
> >>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action
> =
> >>>>>> null</soapenv:Text></soapenv:Reason>
> >>>>>>
> >>>>>> while getMostActiveArtist() gives:
> >>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
> >>>>>> SOAPAction: urn:getMostActiveArtist
> >>>>>> User-Agent: Axis2
> >>>>>>
> >>>>>> And the same error response.
> >>>>>>
> >>>>>> Shouldn't the bindings be appending the operation name onto the end
> >>>>>> of
> >>>>>> the
> >>>>>> endpoint for me? If I explicitly set the endpoint to
> >>>>>>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
> >>>>>> it makes the following request:
> >>>>>> GET
> >>>>>>
> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
> >>>>>> HTTP/1.1
> >>>>>> Content-Type: application/x-www-form-urlencoded;
> >>>>>> charset=UTF-8;action="urn:getGigsIn";
> >>>>>> SOAPAction: urn:getGigsIn
> >>>>>> User-Agent: Axis2
> >>>>>>
> >>>>>> Which still gives an error, but this time:
> >>>>>> <soapenv:Reason
> >>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope
> "><soapenv:Text
> >>>>>> xml:lang="en-US">Exception occurred while trying to invoke service
> >>>>>> method
> >>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
> >>>>>>
> >>>>>> If I simply go to
> >>>>>>
> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
> >>>>>> in my browser I get the correct response.
> >>>>>
> >>>>> The above should work for you correctly with codegenerated stubs. Can
> >>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
> >>>>> invocation for this release and verified that these stuff work.
> >>>>>>
> >>>>>> For me, one of the advantages of the generated bindings is not
> having
> >>>>>> to
> >>>>>> worry about the contents of the WSDL; I shouldn't have to know that
> >>>>>> the
> >>>>>> WSDL
> >>>>>> says I must specify the "city" parameter in my query string for the
> >>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
> >>>>>> instead?
> >>>>>
> >>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
> >>>>> answer to this.
> >>>>>>
> >>>>>>
> >>>>>> Finally, the documentation specifies that Axis2 determines if an
> >>>>>> incoming
> >>>>>> message is REST or SOAP by checking if "the content type is text/xml
> >>>>>> and
> >>>>>> if
> >>>>>> the SOAPAction Header is missing". If you examine the requests the
> >>>>>> following headers are present for each method.
> >>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
> >>>>>> HTTP_POST: Just SOAPAction
> >>>>>> SOAP: Just "action" in Content-Type
> >>>>>>
> >>>>>> What is going on here, are these the correct headers? And what is
> the
> >>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
> >>>>>> Content-Type!?
> >>>>>> I also found that when using POST I can even remove the SOAPAction
> >>>>>> header
> >>>>>> but providing I ensure the Content-Type still contains
> >>>>>> "application/xml"
> >>>>>> I
> >>>>>> will still receive the correct (non-soap) response from the service.
> >>>>>>
> >>>>>>
> >>>>>> I'm aware I might be doing something fundamentally wrong on the
> >>>>>> client
> >>>>>> side
> >>>>>> (maybe you can't use ADB bindings?) to get these results and I'd be
> >>>>>> very
> >>>>>> grateful for any responses to any of these questions.
> >>>>>
> >>>>> You can use codegenerated stub to invoke REST services.
> >>>>>
> >>>>> Thanks,
> >>>>> Keith.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Nick
> >>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
> >>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Keith Chapman
> >>>>> Senior Software Engineer
> >>>>> WSO2 Inc.
> >>>>> Oxygenating the Web Service Platform.
> >>>>> http://wso2.org/
> >>>>>
> >>>>> blog: http://www.keith-chapman.org
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
> >>>> Sent from the Axis - User mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Keith Chapman
> >>> Senior Software Engineer
> >>> WSO2 Inc.
> >>> Oxygenating the Web Service Platform.
> >>> http://wso2.org/
> >>>
> >>> blog: http://www.keith-chapman.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
> >> Sent from the Axis - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Keith Chapman
> > Senior Software Engineer
> > WSO2 Inc.
> > Oxygenating the Web Service Platform.
> > http://wso2.org/
> >
> > blog: http://www.keith-chapman.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
I have now generated the httpbindings using wsdl2java with a version 2.0 wsdl
and the operation has been added to the EPR as desired and I can do POST
getGigsIn("London"), POST getMostActiveArtist() and GET
getMostActiveArtist() without any problems which is great. The headers for
both GET and POST are also now the same (see below) which makes a lot more
sense to me.
Content-Type: application/xml; charset=UTF-8
SOAPAction: ""
However, when I try to do GET getGigsIn("London") I get the error
<faultstring>unknown</faultstring>. The request according to TCPmon is:
GET
/NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn
HTTP/1.1
Content-Type: application/xml; charset=UTF-8
SOAPAction: ""
User-Agent: Axis2
Host: 10.4.39.241:8089
The operation is there in the URL but the parameter "London" is not so it's
obviously not going to work. I was expecting something more like
GET
/NicksGigs-war-Axis2/services/GigListingsService/NicksGigsServiceV2/getGigsIn?city=London
HTTP/1.1
Whats going wrong here?
Also, just to see what would happen, I tried to make some httpbindings using
a version 1.1 wsdl but the generated stub had methods like void getGigsIn()
and void getMostActiveArtist() which don't take or return any values so I
couldn't work out how I could possibly use them. Is this normal or is this
the reason you said to use a version 2.0 wsdl?
Cheers,
Nick
keith chapman wrote:
>
> On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
> <ni...@imperial.ac.uk> wrote:
>>
>> Keith,
>>
>> I had no idea ?wsdl2 even existed,
>
> Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
> HTTPBinding can describe a REST interface for your service in a nice
> manner.
>
> I've no idea how I managed to miss this
>> but I will hunt for it tomorrow and give it a go. Thanks very much this
>> reply, what you say aout the EPR has definitely cleared some things up
>> for
>> me and hopefully I can now go on to get this to work.
>>
>> Just to be clear though, you say I should generate the client stub for
>> the
>> httpbinding, how exactly do I do this? I thought the stub I already had
>> could handle all the bindings in my wsdl and that setting the portal
>> parameters was what controlled which binding was being used. Is this
>> wrong?
>
> When codegeneration is used to generate the server side code its only
> the portType (or the interface if WSDL 2.0) that we care about when
> generating code. But when its generating code for the client side we
> generate it for a particular port and you can specify this by using
> the -pn option. If a port if not provided it faults to use the first
> SOAP 1.2 port it finds. You could generate code for all ports too this
> can be done by using the -ap options. This will generate stubs for all
> ports in the WSDL. So for example if I take the same RESTSample that I
> used yesterday this is how I would generate code for its HTTPBinding.
>
> wsdl2java.sh -uri http://mooshup.com/services/samples/RESTSample?wsdl2
> -pn HTTPEndpoint -wv 2
>
> I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
>
> Thanks,
> Keith.
>>
>> Cheers,
>> Nick
>>
>>
>> keith chapman wrote:
>>>
>>> Hi Nick,
>>>
>>> If you want to invoke a service using REST then its better to generate
>>> the client stub for the httpBinding (and when doing so I recommend you
>>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
>>> interface of the service. This is where it will contain details of the
>>> URL the operation is available at hence if this binding is used to
>>> invoke the service it will automatically add the operation name to the
>>> end of the EPR. This does not happen for the SOAP bindings though.
>>> This is the reason for the behavior you observed below.
>>>
>>> In the request you have sent below does not contain enough information
>>> to dispatch it to the correct operation of the service. If you had the
>>> operation name at the end of it it would have worked. And BTW when you
>>> are using service client directly it will not append the operation
>>> name to the EPR. Note that you have to configure the ServiceClient
>>> your self when using this. (This is not the case for stubs generated
>>> for the httpBinding though).
>>>
>>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
>>> <ni...@imperial.ac.uk> wrote:
>>>>
>>>> Thank you Jay and Keith for your replies. I've upgraded to version
>>>> 1.4.1
>>>> but
>>>> this had made no difference. Below is a really simple version of my
>>>> code
>>>> taking the options used by Jay in his working service but I can still
>>>> only
>>>> get the correct response using getGigsIn() with POST, every other
>>>> combination else fails with:
>>>> <soapenv:Reason
>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>>>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for
>>>> the
>>>> Operation not found is /NicksGigs-war-Axis2/services/GigListingsService
>>>> and
>>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>>>>
>>>> SimpleREST.java:
>>>> String epr =
>>>> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>>>> Options options = portal._getServiceClient().getOptions();
>>>> options.setProperty(Constants.Configuration.ENABLE_REST, Boolean.TRUE);
>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>> Constants.Configuration.HTTP_METHOD_POST);
>>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>>>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>>>> Constants.VALUE_TRUE);
>>>> options.setCallTransportCleanup(true);
>>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>>>> portal._getServiceClient().setOptions(options);
>>>> Gig[] results = portal.getGigsIn("London");
>>>> for (int j = 0; j < results.length; j++)
>>>> System.out.println(results[j].getToString());
>>>>
>>>> Note that I had to comment out the MESSAGE_TYPE property for this to
>>>> work. I
>>>> have also commented out the SOAP_ACTION property here since although it
>>>> did
>>>> remove the action(s) in the header it didn't make any difference to the
>>>> end
>>>> result.
>>>>
>>>> The thing which strikes me most about this is that whether using GET or
>>>> POST
>>>> the bindings do not append the method names to the endpoint like I
>>>> would
>>>> expect them to. I wrongly assumed that at some point the axis
>>>> generated
>>>> code would do something like endpoint+"/"+methodName but it doesn't
>>>> seem
>>>> to... Is this correct behaviour?
>>>>
>>>> I took a look at the blog entry and after a closer look at my WSDL it
>>>> seems
>>>> that the one generated at
>>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the correct
>>>> parameter names, but the wsdl generated by the maven java2wsdl plugin
>>>> and
>>>> then subsequently used by wsdl2java to create my stub has the param0,
>>>> param1
>>>> names. Maven automatically compiles with debug on and I've made no
>>>> changes
>>>> to this so I am a bit confused why I'm getting this. Even more so by
>>>> the
>>>> fact that if I create unwrapped bindings then the correct parameter
>>>> names
>>>> are used.
>>>
>>> This is strange. I haven't tried this out though (wsdl2java maven
>>> plugin). Would give it a try and let you know.
>>>
>>> Thanks,
>>> Keith.
>>>>
>>>> Thanks
>>>> Nick
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> keith chapman wrote:
>>>>>
>>>>> Hi Nick,
>>>>>
>>>>> Sorry I couldn't get back to you sooner. Was held up with some travel
>>>>> last week. So here goes, see my comments inline. (As a summary could
>>>>> you try this with 1.4.1 as I did fix some REST bugs for this release)
>>>>>
>>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>>>>> <ni...@imperial.ac.uk> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've recently started looking at using the REST support in Axis2 to
>>>>>> invoke
>>>>>> my web service instead of the currently used SOAP calls and I have a
>>>>>> number
>>>>>> of issues I can't work out for myself. Any help with these would be
>>>>>> great.
>>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the
>>>>>> hope
>>>>>> my
>>>>>> issues would be solved) and tcpmon to monitor the traffic between my
>>>>>> test
>>>>>> client and my service running locally on tomcat at
>
>>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>>>>>> The
>>>>>> WSDL is created using java2wsdl and is attached.
>>>>>>
>>>>>> I've read in another (old) post here that Axis2 is just a soap stack
>>>>>> and
>>>>>> any
>>>>>> incoming rest style messages are converted into soap messages first
>>>>>> so
>>>>>> that
>>>>>> they can then be processed. Is this still the case?
>>>>>
>>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
>>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>>>>> message we do create a SOAP message out of it.
>>>>>
>>>>> Does this have a
>>>>>> performance hit? Is there anything in the documentation about this?
>>>>>>
>>>>>>
>>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
>>>>>> client, to use the rest style web calls with the bindings is it
>>>>>> simply
>>>>>> a
>>>>>> case of adding the line of code below into my client?
>>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>>>>>> Constants.VALUE_TRUE);
>>>>>> I want to clarify this since all the examples I have seen do not use
>>>>>> bindings.
>>>>>>
>>>>>>
>>>>>> Is it possible to use both POST and GET when my operation parameters
>>>>>> are
>>>>>> all
>>>>>> simple types? To change between the two transports is it simply a
>>>>>> case
>>>>>> of
>>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>>>> HTTP_METHOD_GET);
>>>>>> Or
>>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>>>> HTTP_METHOD_POST);
>>>>>> ?
>>>>>
>>>>> Yes you could set the HTTP Method you need as explained above. Axis2
>>>>> also supports PUT and DELETE.
>>>>>>
>>>>>>
>>>>>> I've found that I can use POST with operations that have parameters
>>>>>> but
>>>>>> not
>>>>>> on those without parameters. For example, a call to
>>>>>> getGigsIn("London")
>>>>>> using HTTP_POST makes the following successful request:
>>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>>>> Content-Type: application/xml; charset=UTF-8
>>>>>> SOAPAction: urn:getGigsIn
>>>>>> User-Agent: Axis2
>>>>>> Content-Length: 115
>>>>>>
>>>>>> <ns2:getGigsIn
>>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>>>>>>
>>>>>> But a call to getMostActiveArtist() makes the following unsuccessful
>>>>>> request:
>>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>>>> Content-Type: application/xml; charset=UTF-8
>>>>>> SOAPAction: urn:getMostActiveArtist
>>>>>> User-Agent: Axis2
>>>>>> Content-Length: 0
>>>>>>
>>>>>> with received error:
>>>>>> <faultstring>The endpoint reference (EPR) for the Operation not found
>>>>>> is
>>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>>>>> null</faultstring>
>>>>>>
>>>>>> Why doesn't this work??
>>>>>>
>>>>>>
>>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
>>>>>> successful
>>>>>> calls to my service. getGigsIn("London") gives:
>>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>>>>>> HTTP/1.1
>>>>>> Content-Type: application/x-www-form-urlencoded;
>>>>>> charset=UTF-8;action="urn:getGigsIn";
>>>>>> SOAPAction: urn:getGigsIn
>>>>>> User-Agent: Axis2
>>>>>>
>>>>>> <soapenv:Reason
>>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not
>>>>>> found
>>>>>> is
>>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>>>>> null</soapenv:Text></soapenv:Reason>
>>>>>>
>>>>>> while getMostActiveArtist() gives:
>>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>>>> Content-Type: application/x-www-form-urlencoded;
>>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>>>>>> SOAPAction: urn:getMostActiveArtist
>>>>>> User-Agent: Axis2
>>>>>>
>>>>>> And the same error response.
>>>>>>
>>>>>> Shouldn't the bindings be appending the operation name onto the end
>>>>>> of
>>>>>> the
>>>>>> endpoint for me? If I explicitly set the endpoint to
>>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>>>>>> it makes the following request:
>>>>>> GET
>>>>>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>>>>>> HTTP/1.1
>>>>>> Content-Type: application/x-www-form-urlencoded;
>>>>>> charset=UTF-8;action="urn:getGigsIn";
>>>>>> SOAPAction: urn:getGigsIn
>>>>>> User-Agent: Axis2
>>>>>>
>>>>>> Which still gives an error, but this time:
>>>>>> <soapenv:Reason
>>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>>>>> xml:lang="en-US">Exception occurred while trying to invoke service
>>>>>> method
>>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>>>>>>
>>>>>> If I simply go to
>>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>>>>>> in my browser I get the correct response.
>>>>>
>>>>> The above should work for you correctly with codegenerated stubs. Can
>>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
>>>>> invocation for this release and verified that these stuff work.
>>>>>>
>>>>>> For me, one of the advantages of the generated bindings is not having
>>>>>> to
>>>>>> worry about the contents of the WSDL; I shouldn't have to know that
>>>>>> the
>>>>>> WSDL
>>>>>> says I must specify the "city" parameter in my query string for the
>>>>>> getGigsIn operation. Why are my ADB bindings setting "param0"
>>>>>> instead?
>>>>>
>>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
>>>>> answer to this.
>>>>>>
>>>>>>
>>>>>> Finally, the documentation specifies that Axis2 determines if an
>>>>>> incoming
>>>>>> message is REST or SOAP by checking if "the content type is text/xml
>>>>>> and
>>>>>> if
>>>>>> the SOAPAction Header is missing". If you examine the requests the
>>>>>> following headers are present for each method.
>>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>>>>>> HTTP_POST: Just SOAPAction
>>>>>> SOAP: Just "action" in Content-Type
>>>>>>
>>>>>> What is going on here, are these the correct headers? And what is the
>>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>>>>>> Content-Type!?
>>>>>> I also found that when using POST I can even remove the SOAPAction
>>>>>> header
>>>>>> but providing I ensure the Content-Type still contains
>>>>>> "application/xml"
>>>>>> I
>>>>>> will still receive the correct (non-soap) response from the service.
>>>>>>
>>>>>>
>>>>>> I'm aware I might be doing something fundamentally wrong on the
>>>>>> client
>>>>>> side
>>>>>> (maybe you can't use ADB bindings?) to get these results and I'd be
>>>>>> very
>>>>>> grateful for any responses to any of these questions.
>>>>>
>>>>> You can use codegenerated stub to invoke REST services.
>>>>>
>>>>> Thanks,
>>>>> Keith.
>>>>>>
>>>>>> Thanks,
>>>>>> Nick
>>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Keith Chapman
>>>>> Senior Software Engineer
>>>>> WSO2 Inc.
>>>>> Oxygenating the Web Service Platform.
>>>>> http://wso2.org/
>>>>>
>>>>> blog: http://www.keith-chapman.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Keith Chapman
>>> Senior Software Engineer
>>> WSO2 Inc.
>>> Oxygenating the Web Service Platform.
>>> http://wso2.org/
>>>
>>> blog: http://www.keith-chapman.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19274912.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Posted by keith chapman <ke...@gmail.com>.
On Tue, Sep 2, 2008 at 2:11 AM, Nick Steel
<ni...@imperial.ac.uk> wrote:
>
> Keith,
>
> I had no idea ?wsdl2 even existed,
Axis2 supports both WSDL 1.1 and WSDL 2.0. And the WSDL 2.0
HTTPBinding can describe a REST interface for your service in a nice
manner.
I've no idea how I managed to miss this
> but I will hunt for it tomorrow and give it a go. Thanks very much this
> reply, what you say aout the EPR has definitely cleared some things up for
> me and hopefully I can now go on to get this to work.
>
> Just to be clear though, you say I should generate the client stub for the
> httpbinding, how exactly do I do this? I thought the stub I already had
> could handle all the bindings in my wsdl and that setting the portal
> parameters was what controlled which binding was being used. Is this wrong?
When codegeneration is used to generate the server side code its only
the portType (or the interface if WSDL 2.0) that we care about when
generating code. But when its generating code for the client side we
generate it for a particular port and you can specify this by using
the -pn option. If a port if not provided it faults to use the first
SOAP 1.2 port it finds. You could generate code for all ports too this
can be done by using the -ap options. This will generate stubs for all
ports in the WSDL. So for example if I take the same RESTSample that I
used yesterday this is how I would generate code for its HTTPBinding.
wsdl2java.sh -uri http://mooshup.com/services/samples/RESTSample?wsdl2
-pn HTTPEndpoint -wv 2
I use "-wv 2" to specify that this is indeed a WSDL 2.0 file.
Thanks,
Keith.
>
> Cheers,
> Nick
>
>
> keith chapman wrote:
>>
>> Hi Nick,
>>
>> If you want to invoke a service using REST then its better to generate
>> the client stub for the httpBinding (and when doing so I recommend you
>> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
>> interface of the service. This is where it will contain details of the
>> URL the operation is available at hence if this binding is used to
>> invoke the service it will automatically add the operation name to the
>> end of the EPR. This does not happen for the SOAP bindings though.
>> This is the reason for the behavior you observed below.
>>
>> In the request you have sent below does not contain enough information
>> to dispatch it to the correct operation of the service. If you had the
>> operation name at the end of it it would have worked. And BTW when you
>> are using service client directly it will not append the operation
>> name to the EPR. Note that you have to configure the ServiceClient
>> your self when using this. (This is not the case for stubs generated
>> for the httpBinding though).
>>
>> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
>> <ni...@imperial.ac.uk> wrote:
>>>
>>> Thank you Jay and Keith for your replies. I've upgraded to version 1.4.1
>>> but
>>> this had made no difference. Below is a really simple version of my code
>>> taking the options used by Jay in his working service but I can still
>>> only
>>> get the correct response using getGigsIn() with POST, every other
>>> combination else fails with:
>>> <soapenv:Reason xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for
>>> the
>>> Operation not found is /NicksGigs-war-Axis2/services/GigListingsService
>>> and
>>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>>>
>>> SimpleREST.java:
>>> String epr =
>>> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>>> Options options = portal._getServiceClient().getOptions();
>>> options.setProperty(Constants.Configuration.ENABLE_REST, Boolean.TRUE);
>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>> Constants.Configuration.HTTP_METHOD_POST);
>>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>>> Constants.VALUE_TRUE);
>>> options.setCallTransportCleanup(true);
>>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>>> portal._getServiceClient().setOptions(options);
>>> Gig[] results = portal.getGigsIn("London");
>>> for (int j = 0; j < results.length; j++)
>>> System.out.println(results[j].getToString());
>>>
>>> Note that I had to comment out the MESSAGE_TYPE property for this to
>>> work. I
>>> have also commented out the SOAP_ACTION property here since although it
>>> did
>>> remove the action(s) in the header it didn't make any difference to the
>>> end
>>> result.
>>>
>>> The thing which strikes me most about this is that whether using GET or
>>> POST
>>> the bindings do not append the method names to the endpoint like I would
>>> expect them to. I wrongly assumed that at some point the axis generated
>>> code would do something like endpoint+"/"+methodName but it doesn't seem
>>> to... Is this correct behaviour?
>>>
>>> I took a look at the blog entry and after a closer look at my WSDL it
>>> seems
>>> that the one generated at
>>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the correct
>>> parameter names, but the wsdl generated by the maven java2wsdl plugin and
>>> then subsequently used by wsdl2java to create my stub has the param0,
>>> param1
>>> names. Maven automatically compiles with debug on and I've made no
>>> changes
>>> to this so I am a bit confused why I'm getting this. Even more so by the
>>> fact that if I create unwrapped bindings then the correct parameter names
>>> are used.
>>
>> This is strange. I haven't tried this out though (wsdl2java maven
>> plugin). Would give it a try and let you know.
>>
>> Thanks,
>> Keith.
>>>
>>> Thanks
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> keith chapman wrote:
>>>>
>>>> Hi Nick,
>>>>
>>>> Sorry I couldn't get back to you sooner. Was held up with some travel
>>>> last week. So here goes, see my comments inline. (As a summary could
>>>> you try this with 1.4.1 as I did fix some REST bugs for this release)
>>>>
>>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>>>> <ni...@imperial.ac.uk> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've recently started looking at using the REST support in Axis2 to
>>>>> invoke
>>>>> my web service instead of the currently used SOAP calls and I have a
>>>>> number
>>>>> of issues I can't work out for myself. Any help with these would be
>>>>> great.
>>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the hope
>>>>> my
>>>>> issues would be solved) and tcpmon to monitor the traffic between my
>>>>> test
>>>>> client and my service running locally on tomcat at
>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>>>>> The
>>>>> WSDL is created using java2wsdl and is attached.
>>>>>
>>>>> I've read in another (old) post here that Axis2 is just a soap stack
>>>>> and
>>>>> any
>>>>> incoming rest style messages are converted into soap messages first so
>>>>> that
>>>>> they can then be processed. Is this still the case?
>>>>
>>>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
>>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>>>> message we do create a SOAP message out of it.
>>>>
>>>> Does this have a
>>>>> performance hit? Is there anything in the documentation about this?
>>>>>
>>>>>
>>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
>>>>> client, to use the rest style web calls with the bindings is it simply
>>>>> a
>>>>> case of adding the line of code below into my client?
>>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>>>>> Constants.VALUE_TRUE);
>>>>> I want to clarify this since all the examples I have seen do not use
>>>>> bindings.
>>>>>
>>>>>
>>>>> Is it possible to use both POST and GET when my operation parameters
>>>>> are
>>>>> all
>>>>> simple types? To change between the two transports is it simply a case
>>>>> of
>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>>> HTTP_METHOD_GET);
>>>>> Or
>>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>>> HTTP_METHOD_POST);
>>>>> ?
>>>>
>>>> Yes you could set the HTTP Method you need as explained above. Axis2
>>>> also supports PUT and DELETE.
>>>>>
>>>>>
>>>>> I've found that I can use POST with operations that have parameters but
>>>>> not
>>>>> on those without parameters. For example, a call to
>>>>> getGigsIn("London")
>>>>> using HTTP_POST makes the following successful request:
>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>>> Content-Type: application/xml; charset=UTF-8
>>>>> SOAPAction: urn:getGigsIn
>>>>> User-Agent: Axis2
>>>>> Content-Length: 115
>>>>>
>>>>> <ns2:getGigsIn
>>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>>>>>
>>>>> But a call to getMostActiveArtist() makes the following unsuccessful
>>>>> request:
>>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>>> Content-Type: application/xml; charset=UTF-8
>>>>> SOAPAction: urn:getMostActiveArtist
>>>>> User-Agent: Axis2
>>>>> Content-Length: 0
>>>>>
>>>>> with received error:
>>>>> <faultstring>The endpoint reference (EPR) for the Operation not found
>>>>> is
>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>>>> null</faultstring>
>>>>>
>>>>> Why doesn't this work??
>>>>>
>>>>>
>>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
>>>>> successful
>>>>> calls to my service. getGigsIn("London") gives:
>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>>>>> HTTP/1.1
>>>>> Content-Type: application/x-www-form-urlencoded;
>>>>> charset=UTF-8;action="urn:getGigsIn";
>>>>> SOAPAction: urn:getGigsIn
>>>>> User-Agent: Axis2
>>>>>
>>>>> <soapenv:Reason
>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not
>>>>> found
>>>>> is
>>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>>>> null</soapenv:Text></soapenv:Reason>
>>>>>
>>>>> while getMostActiveArtist() gives:
>>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>>> Content-Type: application/x-www-form-urlencoded;
>>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>>>>> SOAPAction: urn:getMostActiveArtist
>>>>> User-Agent: Axis2
>>>>>
>>>>> And the same error response.
>>>>>
>>>>> Shouldn't the bindings be appending the operation name onto the end of
>>>>> the
>>>>> endpoint for me? If I explicitly set the endpoint to
>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>>>>> it makes the following request:
>>>>> GET
>>>>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>>>>> HTTP/1.1
>>>>> Content-Type: application/x-www-form-urlencoded;
>>>>> charset=UTF-8;action="urn:getGigsIn";
>>>>> SOAPAction: urn:getGigsIn
>>>>> User-Agent: Axis2
>>>>>
>>>>> Which still gives an error, but this time:
>>>>> <soapenv:Reason
>>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>>>> xml:lang="en-US">Exception occurred while trying to invoke service
>>>>> method
>>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>>>>>
>>>>> If I simply go to
>>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>>>>> in my browser I get the correct response.
>>>>
>>>> The above should work for you correctly with codegenerated stubs. Can
>>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
>>>> invocation for this release and verified that these stuff work.
>>>>>
>>>>> For me, one of the advantages of the generated bindings is not having
>>>>> to
>>>>> worry about the contents of the WSDL; I shouldn't have to know that the
>>>>> WSDL
>>>>> says I must specify the "city" parameter in my query string for the
>>>>> getGigsIn operation. Why are my ADB bindings setting "param0" instead?
>>>>
>>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
>>>> answer to this.
>>>>>
>>>>>
>>>>> Finally, the documentation specifies that Axis2 determines if an
>>>>> incoming
>>>>> message is REST or SOAP by checking if "the content type is text/xml
>>>>> and
>>>>> if
>>>>> the SOAPAction Header is missing". If you examine the requests the
>>>>> following headers are present for each method.
>>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>>>>> HTTP_POST: Just SOAPAction
>>>>> SOAP: Just "action" in Content-Type
>>>>>
>>>>> What is going on here, are these the correct headers? And what is the
>>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>>>>> Content-Type!?
>>>>> I also found that when using POST I can even remove the SOAPAction
>>>>> header
>>>>> but providing I ensure the Content-Type still contains
>>>>> "application/xml"
>>>>> I
>>>>> will still receive the correct (non-soap) response from the service.
>>>>>
>>>>>
>>>>> I'm aware I might be doing something fundamentally wrong on the client
>>>>> side
>>>>> (maybe you can't use ADB bindings?) to get these results and I'd be
>>>>> very
>>>>> grateful for any responses to any of these questions.
>>>>
>>>> You can use codegenerated stub to invoke REST services.
>>>>
>>>> Thanks,
>>>> Keith.
>>>>>
>>>>> Thanks,
>>>>> Nick
>>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Keith Chapman
>>>> Senior Software Engineer
>>>> WSO2 Inc.
>>>> Oxygenating the Web Service Platform.
>>>> http://wso2.org/
>>>>
>>>> blog: http://www.keith-chapman.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Keith Chapman
>> Senior Software Engineer
>> WSO2 Inc.
>> Oxygenating the Web Service Platform.
>> http://wso2.org/
>>
>> blog: http://www.keith-chapman.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
Keith,
I had no idea ?wsdl2 even existed, I've no idea how I managed to miss this
but I will hunt for it tomorrow and give it a go. Thanks very much this
reply, what you say aout the EPR has definitely cleared some things up for
me and hopefully I can now go on to get this to work.
Just to be clear though, you say I should generate the client stub for the
httpbinding, how exactly do I do this? I thought the stub I already had
could handle all the bindings in my wsdl and that setting the portal
parameters was what controlled which binding was being used. Is this wrong?
Cheers,
Nick
keith chapman wrote:
>
> Hi Nick,
>
> If you want to invoke a service using REST then its better to generate
> the client stub for the httpBinding (and when doing so I recommend you
> to use ?wsdl2 instead of ?wsdl). This is what describes the REST
> interface of the service. This is where it will contain details of the
> URL the operation is available at hence if this binding is used to
> invoke the service it will automatically add the operation name to the
> end of the EPR. This does not happen for the SOAP bindings though.
> This is the reason for the behavior you observed below.
>
> In the request you have sent below does not contain enough information
> to dispatch it to the correct operation of the service. If you had the
> operation name at the end of it it would have worked. And BTW when you
> are using service client directly it will not append the operation
> name to the EPR. Note that you have to configure the ServiceClient
> your self when using this. (This is not the case for stubs generated
> for the httpBinding though).
>
> On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
> <ni...@imperial.ac.uk> wrote:
>>
>> Thank you Jay and Keith for your replies. I've upgraded to version 1.4.1
>> but
>> this had made no difference. Below is a really simple version of my code
>> taking the options used by Jay in his working service but I can still
>> only
>> get the correct response using getGigsIn() with POST, every other
>> combination else fails with:
>> <soapenv:Reason xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for
>> the
>> Operation not found is /NicksGigs-war-Axis2/services/GigListingsService
>> and
>> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>>
>> SimpleREST.java:
>> String epr =
>> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
>> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
>> Options options = portal._getServiceClient().getOptions();
>> options.setProperty(Constants.Configuration.ENABLE_REST, Boolean.TRUE);
>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> Constants.Configuration.HTTP_METHOD_POST);
>> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
>> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
>> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
>> Constants.VALUE_TRUE);
>> options.setCallTransportCleanup(true);
>> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
>> portal._getServiceClient().setOptions(options);
>> Gig[] results = portal.getGigsIn("London");
>> for (int j = 0; j < results.length; j++)
>> System.out.println(results[j].getToString());
>>
>> Note that I had to comment out the MESSAGE_TYPE property for this to
>> work. I
>> have also commented out the SOAP_ACTION property here since although it
>> did
>> remove the action(s) in the header it didn't make any difference to the
>> end
>> result.
>>
>> The thing which strikes me most about this is that whether using GET or
>> POST
>> the bindings do not append the method names to the endpoint like I would
>> expect them to. I wrongly assumed that at some point the axis generated
>> code would do something like endpoint+"/"+methodName but it doesn't seem
>> to... Is this correct behaviour?
>>
>> I took a look at the blog entry and after a closer look at my WSDL it
>> seems
>> that the one generated at
>> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the correct
>> parameter names, but the wsdl generated by the maven java2wsdl plugin and
>> then subsequently used by wsdl2java to create my stub has the param0,
>> param1
>> names. Maven automatically compiles with debug on and I've made no
>> changes
>> to this so I am a bit confused why I'm getting this. Even more so by the
>> fact that if I create unwrapped bindings then the correct parameter names
>> are used.
>
> This is strange. I haven't tried this out though (wsdl2java maven
> plugin). Would give it a try and let you know.
>
> Thanks,
> Keith.
>>
>> Thanks
>> Nick
>>
>>
>>
>>
>>
>> keith chapman wrote:
>>>
>>> Hi Nick,
>>>
>>> Sorry I couldn't get back to you sooner. Was held up with some travel
>>> last week. So here goes, see my comments inline. (As a summary could
>>> you try this with 1.4.1 as I did fix some REST bugs for this release)
>>>
>>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>>> <ni...@imperial.ac.uk> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've recently started looking at using the REST support in Axis2 to
>>>> invoke
>>>> my web service instead of the currently used SOAP calls and I have a
>>>> number
>>>> of issues I can't work out for myself. Any help with these would be
>>>> great.
>>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the hope
>>>> my
>>>> issues would be solved) and tcpmon to monitor the traffic between my
>>>> test
>>>> client and my service running locally on tomcat at
>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>>>> The
>>>> WSDL is created using java2wsdl and is attached.
>>>>
>>>> I've read in another (old) post here that Axis2 is just a soap stack
>>>> and
>>>> any
>>>> incoming rest style messages are converted into soap messages first so
>>>> that
>>>> they can then be processed. Is this still the case?
>>>
>>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
>>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>>> message we do create a SOAP message out of it.
>>>
>>> Does this have a
>>>> performance hit? Is there anything in the documentation about this?
>>>>
>>>>
>>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
>>>> client, to use the rest style web calls with the bindings is it simply
>>>> a
>>>> case of adding the line of code below into my client?
>>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>>>> Constants.VALUE_TRUE);
>>>> I want to clarify this since all the examples I have seen do not use
>>>> bindings.
>>>>
>>>>
>>>> Is it possible to use both POST and GET when my operation parameters
>>>> are
>>>> all
>>>> simple types? To change between the two transports is it simply a case
>>>> of
>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>> HTTP_METHOD_GET);
>>>> Or
>>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>>> HTTP_METHOD_POST);
>>>> ?
>>>
>>> Yes you could set the HTTP Method you need as explained above. Axis2
>>> also supports PUT and DELETE.
>>>>
>>>>
>>>> I've found that I can use POST with operations that have parameters but
>>>> not
>>>> on those without parameters. For example, a call to
>>>> getGigsIn("London")
>>>> using HTTP_POST makes the following successful request:
>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>> Content-Type: application/xml; charset=UTF-8
>>>> SOAPAction: urn:getGigsIn
>>>> User-Agent: Axis2
>>>> Content-Length: 115
>>>>
>>>> <ns2:getGigsIn
>>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>>>>
>>>> But a call to getMostActiveArtist() makes the following unsuccessful
>>>> request:
>>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>> Content-Type: application/xml; charset=UTF-8
>>>> SOAPAction: urn:getMostActiveArtist
>>>> User-Agent: Axis2
>>>> Content-Length: 0
>>>>
>>>> with received error:
>>>> <faultstring>The endpoint reference (EPR) for the Operation not found
>>>> is
>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>>> null</faultstring>
>>>>
>>>> Why doesn't this work??
>>>>
>>>>
>>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
>>>> successful
>>>> calls to my service. getGigsIn("London") gives:
>>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>>>> HTTP/1.1
>>>> Content-Type: application/x-www-form-urlencoded;
>>>> charset=UTF-8;action="urn:getGigsIn";
>>>> SOAPAction: urn:getGigsIn
>>>> User-Agent: Axis2
>>>>
>>>> <soapenv:Reason
>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not
>>>> found
>>>> is
>>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>>> null</soapenv:Text></soapenv:Reason>
>>>>
>>>> while getMostActiveArtist() gives:
>>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>>> Content-Type: application/x-www-form-urlencoded;
>>>> charset=UTF-8;action="urn:getMostActiveArtist";
>>>> SOAPAction: urn:getMostActiveArtist
>>>> User-Agent: Axis2
>>>>
>>>> And the same error response.
>>>>
>>>> Shouldn't the bindings be appending the operation name onto the end of
>>>> the
>>>> endpoint for me? If I explicitly set the endpoint to
>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>>>> it makes the following request:
>>>> GET
>>>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>>>> HTTP/1.1
>>>> Content-Type: application/x-www-form-urlencoded;
>>>> charset=UTF-8;action="urn:getGigsIn";
>>>> SOAPAction: urn:getGigsIn
>>>> User-Agent: Axis2
>>>>
>>>> Which still gives an error, but this time:
>>>> <soapenv:Reason
>>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>>> xml:lang="en-US">Exception occurred while trying to invoke service
>>>> method
>>>> getGigsIn</soapenv:Text></soapenv:Reason>
>>>>
>>>> If I simply go to
>>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>>>> in my browser I get the correct response.
>>>
>>> The above should work for you correctly with codegenerated stubs. Can
>>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
>>> invocation for this release and verified that these stuff work.
>>>>
>>>> For me, one of the advantages of the generated bindings is not having
>>>> to
>>>> worry about the contents of the WSDL; I shouldn't have to know that the
>>>> WSDL
>>>> says I must specify the "city" parameter in my query string for the
>>>> getGigsIn operation. Why are my ADB bindings setting "param0" instead?
>>>
>>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
>>> answer to this.
>>>>
>>>>
>>>> Finally, the documentation specifies that Axis2 determines if an
>>>> incoming
>>>> message is REST or SOAP by checking if "the content type is text/xml
>>>> and
>>>> if
>>>> the SOAPAction Header is missing". If you examine the requests the
>>>> following headers are present for each method.
>>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>>>> HTTP_POST: Just SOAPAction
>>>> SOAP: Just "action" in Content-Type
>>>>
>>>> What is going on here, are these the correct headers? And what is the
>>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>>>> Content-Type!?
>>>> I also found that when using POST I can even remove the SOAPAction
>>>> header
>>>> but providing I ensure the Content-Type still contains
>>>> "application/xml"
>>>> I
>>>> will still receive the correct (non-soap) response from the service.
>>>>
>>>>
>>>> I'm aware I might be doing something fundamentally wrong on the client
>>>> side
>>>> (maybe you can't use ADB bindings?) to get these results and I'd be
>>>> very
>>>> grateful for any responses to any of these questions.
>>>
>>> You can use codegenerated stub to invoke REST services.
>>>
>>> Thanks,
>>> Keith.
>>>>
>>>> Thanks,
>>>> Nick
>>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Keith Chapman
>>> Senior Software Engineer
>>> WSO2 Inc.
>>> Oxygenating the Web Service Platform.
>>> http://wso2.org/
>>>
>>> blog: http://www.keith-chapman.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19260445.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Posted by keith chapman <ke...@gmail.com>.
Hi Nick,
If you want to invoke a service using REST then its better to generate
the client stub for the httpBinding (and when doing so I recommend you
to use ?wsdl2 instead of ?wsdl). This is what describes the REST
interface of the service. This is where it will contain details of the
URL the operation is available at hence if this binding is used to
invoke the service it will automatically add the operation name to the
end of the EPR. This does not happen for the SOAP bindings though.
This is the reason for the behavior you observed below.
In the request you have sent below does not contain enough information
to dispatch it to the correct operation of the service. If you had the
operation name at the end of it it would have worked. And BTW when you
are using service client directly it will not append the operation
name to the EPR. Note that you have to configure the ServiceClient
your self when using this. (This is not the case for stubs generated
for the httpBinding though).
On Mon, Sep 1, 2008 at 9:07 PM, Nick Steel
<ni...@imperial.ac.uk> wrote:
>
> Thank you Jay and Keith for your replies. I've upgraded to version 1.4.1 but
> this had made no difference. Below is a really simple version of my code
> taking the options used by Jay in his working service but I can still only
> get the correct response using getGigsIn() with POST, every other
> combination else fails with:
> <soapenv:Reason xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> <soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for the
> Operation not found is /NicksGigs-war-Axis2/services/GigListingsService and
> the WSA Action = null</soapenv:Text></soapenv:Reason>"
>
> SimpleREST.java:
> String epr =
> "http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
> NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
> Options options = portal._getServiceClient().getOptions();
> options.setProperty(Constants.Configuration.ENABLE_REST, Boolean.TRUE);
> options.setProperty(Constants.Configuration.HTTP_METHOD,
> Constants.Configuration.HTTP_METHOD_POST);
> options.setProperty(Constants.Configuration.MESSAGE_TYPE,
> //org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
> //options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
> Constants.VALUE_TRUE);
> options.setCallTransportCleanup(true);
> options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
> portal._getServiceClient().setOptions(options);
> Gig[] results = portal.getGigsIn("London");
> for (int j = 0; j < results.length; j++)
> System.out.println(results[j].getToString());
>
> Note that I had to comment out the MESSAGE_TYPE property for this to work. I
> have also commented out the SOAP_ACTION property here since although it did
> remove the action(s) in the header it didn't make any difference to the end
> result.
>
> The thing which strikes me most about this is that whether using GET or POST
> the bindings do not append the method names to the endpoint like I would
> expect them to. I wrongly assumed that at some point the axis generated
> code would do something like endpoint+"/"+methodName but it doesn't seem
> to... Is this correct behaviour?
>
> I took a look at the blog entry and after a closer look at my WSDL it seems
> that the one generated at
> ...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the correct
> parameter names, but the wsdl generated by the maven java2wsdl plugin and
> then subsequently used by wsdl2java to create my stub has the param0, param1
> names. Maven automatically compiles with debug on and I've made no changes
> to this so I am a bit confused why I'm getting this. Even more so by the
> fact that if I create unwrapped bindings then the correct parameter names
> are used.
This is strange. I haven't tried this out though (wsdl2java maven
plugin). Would give it a try and let you know.
Thanks,
Keith.
>
> Thanks
> Nick
>
>
>
>
>
> keith chapman wrote:
>>
>> Hi Nick,
>>
>> Sorry I couldn't get back to you sooner. Was held up with some travel
>> last week. So here goes, see my comments inline. (As a summary could
>> you try this with 1.4.1 as I did fix some REST bugs for this release)
>>
>> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
>> <ni...@imperial.ac.uk> wrote:
>>>
>>> Hi,
>>>
>>> I've recently started looking at using the REST support in Axis2 to
>>> invoke
>>> my web service instead of the currently used SOAP calls and I have a
>>> number
>>> of issues I can't work out for myself. Any help with these would be
>>> great.
>>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the hope my
>>> issues would be solved) and tcpmon to monitor the traffic between my test
>>> client and my service running locally on tomcat at
>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>>> The
>>> WSDL is created using java2wsdl and is attached.
>>>
>>> I've read in another (old) post here that Axis2 is just a soap stack and
>>> any
>>> incoming rest style messages are converted into soap messages first so
>>> that
>>> they can then be processed. Is this still the case?
>>
>> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
>> into axis2 it has a SOAP message. So when Axis2 receives a REST
>> message we do create a SOAP message out of it.
>>
>> Does this have a
>>> performance hit? Is there anything in the documentation about this?
>>>
>>>
>>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
>>> client, to use the rest style web calls with the bindings is it simply a
>>> case of adding the line of code below into my client?
>>> options.setProperty(Constants.Configuration.ENABLE_REST,
>>> Constants.VALUE_TRUE);
>>> I want to clarify this since all the examples I have seen do not use
>>> bindings.
>>>
>>>
>>> Is it possible to use both POST and GET when my operation parameters are
>>> all
>>> simple types? To change between the two transports is it simply a case
>>> of
>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>> HTTP_METHOD_GET);
>>> Or
>>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>>> HTTP_METHOD_POST);
>>> ?
>>
>> Yes you could set the HTTP Method you need as explained above. Axis2
>> also supports PUT and DELETE.
>>>
>>>
>>> I've found that I can use POST with operations that have parameters but
>>> not
>>> on those without parameters. For example, a call to getGigsIn("London")
>>> using HTTP_POST makes the following successful request:
>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>> Content-Type: application/xml; charset=UTF-8
>>> SOAPAction: urn:getGigsIn
>>> User-Agent: Axis2
>>> Content-Length: 115
>>>
>>> <ns2:getGigsIn
>>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>>>
>>> But a call to getMostActiveArtist() makes the following unsuccessful
>>> request:
>>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>> Content-Type: application/xml; charset=UTF-8
>>> SOAPAction: urn:getMostActiveArtist
>>> User-Agent: Axis2
>>> Content-Length: 0
>>>
>>> with received error:
>>> <faultstring>The endpoint reference (EPR) for the Operation not found is
>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>> null</faultstring>
>>>
>>> Why doesn't this work??
>>>
>>>
>>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
>>> successful
>>> calls to my service. getGigsIn("London") gives:
>>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>>> HTTP/1.1
>>> Content-Type: application/x-www-form-urlencoded;
>>> charset=UTF-8;action="urn:getGigsIn";
>>> SOAPAction: urn:getGigsIn
>>> User-Agent: Axis2
>>>
>>> <soapenv:Reason
>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not found
>>> is
>>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>>> null</soapenv:Text></soapenv:Reason>
>>>
>>> while getMostActiveArtist() gives:
>>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>>> Content-Type: application/x-www-form-urlencoded;
>>> charset=UTF-8;action="urn:getMostActiveArtist";
>>> SOAPAction: urn:getMostActiveArtist
>>> User-Agent: Axis2
>>>
>>> And the same error response.
>>>
>>> Shouldn't the bindings be appending the operation name onto the end of
>>> the
>>> endpoint for me? If I explicitly set the endpoint to
>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>>> it makes the following request:
>>> GET
>>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>>> HTTP/1.1
>>> Content-Type: application/x-www-form-urlencoded;
>>> charset=UTF-8;action="urn:getGigsIn";
>>> SOAPAction: urn:getGigsIn
>>> User-Agent: Axis2
>>>
>>> Which still gives an error, but this time:
>>> <soapenv:Reason
>>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>>> xml:lang="en-US">Exception occurred while trying to invoke service method
>>> getGigsIn</soapenv:Text></soapenv:Reason>
>>>
>>> If I simply go to
>>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>>> in my browser I get the correct response.
>>
>> The above should work for you correctly with codegenerated stubs. Can
>> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
>> invocation for this release and verified that these stuff work.
>>>
>>> For me, one of the advantages of the generated bindings is not having to
>>> worry about the contents of the WSDL; I shouldn't have to know that the
>>> WSDL
>>> says I must specify the "city" parameter in my query string for the
>>> getGigsIn operation. Why are my ADB bindings setting "param0" instead?
>>
>> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
>> answer to this.
>>>
>>>
>>> Finally, the documentation specifies that Axis2 determines if an incoming
>>> message is REST or SOAP by checking if "the content type is text/xml and
>>> if
>>> the SOAPAction Header is missing". If you examine the requests the
>>> following headers are present for each method.
>>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>>> HTTP_POST: Just SOAPAction
>>> SOAP: Just "action" in Content-Type
>>>
>>> What is going on here, are these the correct headers? And what is the
>>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>>> Content-Type!?
>>> I also found that when using POST I can even remove the SOAPAction header
>>> but providing I ensure the Content-Type still contains "application/xml"
>>> I
>>> will still receive the correct (non-soap) response from the service.
>>>
>>>
>>> I'm aware I might be doing something fundamentally wrong on the client
>>> side
>>> (maybe you can't use ADB bindings?) to get these results and I'd be very
>>> grateful for any responses to any of these questions.
>>
>> You can use codegenerated stub to invoke REST services.
>>
>> Thanks,
>> Keith.
>>>
>>> Thanks,
>>> Nick
>>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Keith Chapman
>> Senior Software Engineer
>> WSO2 Inc.
>> Oxygenating the Web Service Platform.
>> http://wso2.org/
>>
>> blog: http://www.keith-chapman.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://www.keith-chapman.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis2 REST client and server questions (Data bindings, Headers,
Performance)
Posted by Nick Steel <ni...@imperial.ac.uk>.
Thank you Jay and Keith for your replies. I've upgraded to version 1.4.1 but
this had made no difference. Below is a really simple version of my code
taking the options used by Jay in his working service but I can still only
get the correct response using getGigsIn() with POST, every other
combination else fails with:
<soapenv:Reason xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Text xml:lang="en-US">The endpoint reference (EPR) for the
Operation not found is /NicksGigs-war-Axis2/services/GigListingsService and
the WSA Action = null</soapenv:Text></soapenv:Reason>"
SimpleREST.java:
String epr =
"http://localhost:8089/NicksGigs-war-Axis2/services/GigListingsService";
NicksGigsServiceStub portal = new NicksGigsServiceStub(epr);
Options options = portal._getServiceClient().getOptions();
options.setProperty(Constants.Configuration.ENABLE_REST, Boolean.TRUE);
options.setProperty(Constants.Configuration.HTTP_METHOD,
Constants.Configuration.HTTP_METHOD_POST);
options.setProperty(Constants.Configuration.MESSAGE_TYPE,
//org.apache.axis2.transport.http.HTTPConstants.MEDIA_TYPE_X_WWW_FORM);
//options.setProperty(Constants.Configuration.DISABLE_SOAP_ACTION,
Constants.VALUE_TRUE);
options.setCallTransportCleanup(true);
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
portal._getServiceClient().setOptions(options);
Gig[] results = portal.getGigsIn("London");
for (int j = 0; j < results.length; j++)
System.out.println(results[j].getToString());
Note that I had to comment out the MESSAGE_TYPE property for this to work. I
have also commented out the SOAP_ACTION property here since although it did
remove the action(s) in the header it didn't make any difference to the end
result.
The thing which strikes me most about this is that whether using GET or POST
the bindings do not append the method names to the endpoint like I would
expect them to. I wrongly assumed that at some point the axis generated
code would do something like endpoint+"/"+methodName but it doesn't seem
to... Is this correct behaviour?
I took a look at the blog entry and after a closer look at my WSDL it seems
that the one generated at
...NicksGigs-war-Axis2/services/GigListingsService?wsdl has the correct
parameter names, but the wsdl generated by the maven java2wsdl plugin and
then subsequently used by wsdl2java to create my stub has the param0, param1
names. Maven automatically compiles with debug on and I've made no changes
to this so I am a bit confused why I'm getting this. Even more so by the
fact that if I create unwrapped bindings then the correct parameter names
are used.
Thanks
Nick
keith chapman wrote:
>
> Hi Nick,
>
> Sorry I couldn't get back to you sooner. Was held up with some travel
> last week. So here goes, see my comments inline. (As a summary could
> you try this with 1.4.1 as I did fix some REST bugs for this release)
>
> On Thu, Aug 21, 2008 at 6:12 PM, Nick Steel
> <ni...@imperial.ac.uk> wrote:
>>
>> Hi,
>>
>> I've recently started looking at using the REST support in Axis2 to
>> invoke
>> my web service instead of the currently used SOAP calls and I have a
>> number
>> of issues I can't work out for myself. Any help with these would be
>> great.
>> I've been using Axis2 version 1.3 (and then also tried 1.4 in the hope my
>> issues would be solved) and tcpmon to monitor the traffic between my test
>> client and my service running locally on tomcat at
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService.
>> The
>> WSDL is created using java2wsdl and is attached.
>>
>> I've read in another (old) post here that Axis2 is just a soap stack and
>> any
>> incoming rest style messages are converted into soap messages first so
>> that
>> they can then be processed. Is this still the case?
>
> Yes. Axis2 is primarily a SOAP engine and hence once a message gets
> into axis2 it has a SOAP message. So when Axis2 receives a REST
> message we do create a SOAP message out of it.
>
> Does this have a
>> performance hit? Is there anything in the documentation about this?
>>
>>
>> I'm using (unwrapped) ADB bindings generated by wsdl2java for my test
>> client, to use the rest style web calls with the bindings is it simply a
>> case of adding the line of code below into my client?
>> options.setProperty(Constants.Configuration.ENABLE_REST,
>> Constants.VALUE_TRUE);
>> I want to clarify this since all the examples I have seen do not use
>> bindings.
>>
>>
>> Is it possible to use both POST and GET when my operation parameters are
>> all
>> simple types? To change between the two transports is it simply a case
>> of
>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> HTTP_METHOD_GET);
>> Or
>> options.setProperty(Constants.Configuration.HTTP_METHOD,
>> HTTP_METHOD_POST);
>> ?
>
> Yes you could set the HTTP Method you need as explained above. Axis2
> also supports PUT and DELETE.
>>
>>
>> I've found that I can use POST with operations that have parameters but
>> not
>> on those without parameters. For example, a call to getGigsIn("London")
>> using HTTP_POST makes the following successful request:
>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> Content-Type: application/xml; charset=UTF-8
>> SOAPAction: urn:getGigsIn
>> User-Agent: Axis2
>> Content-Length: 115
>>
>> <ns2:getGigsIn
>> xmlns:ns2="http://NicksGigs.nsteel.qis.qualcomm.com"><ns2:param0>London</ns2:param0></ns2:getGigsIn>
>>
>> But a call to getMostActiveArtist() makes the following unsuccessful
>> request:
>> POST /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> Content-Type: application/xml; charset=UTF-8
>> SOAPAction: urn:getMostActiveArtist
>> User-Agent: Axis2
>> Content-Length: 0
>>
>> with received error:
>> <faultstring>The endpoint reference (EPR) for the Operation not found is
>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>> null</faultstring>
>>
>> Why doesn't this work??
>>
>>
>> After setting the HTTP_METHOD to HTTP_GET I am unable to make any
>> successful
>> calls to my service. getGigsIn("London") gives:
>> GET /NicksGigs-war-Axis2/services/GigListingsService?param0=London
>> HTTP/1.1
>> Content-Type: application/x-www-form-urlencoded;
>> charset=UTF-8;action="urn:getGigsIn";
>> SOAPAction: urn:getGigsIn
>> User-Agent: Axis2
>>
>> <soapenv:Reason
>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>> xml:lang="en-US">The endpoint reference (EPR) for the Operation not found
>> is
>> /NicksGigs-war-Axis2/services/GigListingsService and the WSA Action =
>> null</soapenv:Text></soapenv:Reason>
>>
>> while getMostActiveArtist() gives:
>> GET /NicksGigs-war-Axis2/services/GigListingsService HTTP/1.1
>> Content-Type: application/x-www-form-urlencoded;
>> charset=UTF-8;action="urn:getMostActiveArtist";
>> SOAPAction: urn:getMostActiveArtist
>> User-Agent: Axis2
>>
>> And the same error response.
>>
>> Shouldn't the bindings be appending the operation name onto the end of
>> the
>> endpoint for me? If I explicitly set the endpoint to
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn
>> it makes the following request:
>> GET
>> /NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?param0=London
>> HTTP/1.1
>> Content-Type: application/x-www-form-urlencoded;
>> charset=UTF-8;action="urn:getGigsIn";
>> SOAPAction: urn:getGigsIn
>> User-Agent: Axis2
>>
>> Which still gives an error, but this time:
>> <soapenv:Reason
>> xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Text
>> xml:lang="en-US">Exception occurred while trying to invoke service method
>> getGigsIn</soapenv:Text></soapenv:Reason>
>>
>> If I simply go to
>> http://localhost:8080/NicksGigs-war-Axis2/services/GigListingsService/getGigsIn?city=London
>> in my browser I get the correct response.
>
> The above should work for you correctly with codegenerated stubs. Can
> you try this with Axis2 -1.4.1 please. I fixed some bugs on REST
> invocation for this release and verified that these stuff work.
>>
>> For me, one of the advantages of the generated bindings is not having to
>> worry about the contents of the WSDL; I shouldn't have to know that the
>> WSDL
>> says I must specify the "city" parameter in my query string for the
>> getGigsIn operation. Why are my ADB bindings setting "param0" instead?
>
> This blog entry (http://wso2.org/blog/sumedha/3727) gives you the
> answer to this.
>>
>>
>> Finally, the documentation specifies that Axis2 determines if an incoming
>> message is REST or SOAP by checking if "the content type is text/xml and
>> if
>> the SOAPAction Header is missing". If you examine the requests the
>> following headers are present for each method.
>> HTTP_GET: Both SOAPAction and "action" in Content-Type
>> HTTP_POST: Just SOAPAction
>> SOAP: Just "action" in Content-Type
>>
>> What is going on here, are these the correct headers? And what is the
>> "SOAPAction Header", is it "SOAPAction" or is it "action" in
>> Content-Type!?
>> I also found that when using POST I can even remove the SOAPAction header
>> but providing I ensure the Content-Type still contains "application/xml"
>> I
>> will still receive the correct (non-soap) response from the service.
>>
>>
>> I'm aware I might be doing something fundamentally wrong on the client
>> side
>> (maybe you can't use ADB bindings?) to get these results and I'd be very
>> grateful for any responses to any of these questions.
>
> You can use codegenerated stub to invoke REST services.
>
> Thanks,
> Keith.
>>
>> Thanks,
>> Nick
>> http://www.nabble.com/file/p19087933/example.wsdl example.wsdl
>> --
>> View this message in context:
>> http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19087933.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Axis2-REST-client-and-server-questions-%28Data-bindings%2C-Headers%2C-Performance%29-tp19087933p19256708.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org