axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Steel <nicholas.stee...@imperial.ac.uk>
Subject Re: Axis2 REST client and server questions (Data bindings, Headers, Performance)
Date Fri, 05 Sep 2008 16:29:35 GMT

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
>> <nicholas.steel05@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
>>> >> > <nicholas.steel05@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
>>> >> >>> <nicholas.steel05@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
>>> >> >>>>> <nicholas.steel05@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


Mime
View raw message