You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Senaka Fernando (JIRA)" <ji...@apache.org> on 2007/12/22 23:42:43 UTC

[jira] Issue Comment Edited: (AXIS2C-837) SOAPAction dispatching

    [ https://issues.apache.org/jira/browse/AXIS2C-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554152 ] 

senakafdo edited comment on AXIS2C-837 at 12/22/07 2:41 PM:
------------------------------------------------------------------

Hi Dimuthu and Michael,
Just being curious about what you said, I tried out changing the uri of the request, to include the operation at the end, instead of the operation in the action field of the Content-Type (MIME) header, I used urn:operation, and IT WORKED.

Therefore, this is not a bug. I think you may be missing something in your services.xml or you may be calling an incorrect operation.

We do have four dispatchers invoked along the path of execution.
1. Request uri based
2. WS-Addressing based
3. SOAP action based
4. SOAP message body based

All four can be found inside the src/core/engine folder.

Technically, you should not be having any issue in calling getStatus in DAQStatus.

For an example, you can test this feature using the echo client.

This is what should be done.
1. Change the address to http://localhost:9090/axis2/services/echo/echoString
2. Replace options set action with axis2_options_set_action(options, env, "urn:echoString");
3. Send NULL payload: axis2_svc_client_send_receive(svc_client, env, NULL);
4. Comment out axis2_svc_client_engage_module(svc_client, env, AXIS2_MODULE_ADDRESSING);
5. Disengage addressing in axis2.xml

The exchanged payload would look like,

Request
------------
POST /axis2/services/echo/echoString HTTP/1.1

User-Agent: Axis2/C

Content-Length: 125

Content-Type: application/soap+xml;charset=UTF-8

Host: 127.0.0.1:9090



<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
   <soapenv:Header/>
   <soapenv:Body/></soapenv:Envelope>

Response
---------------
HTTP/1.1 500 Internal Server Error

Content-Type: application/soap+xml;charset=UTF-8

Content-Length: 471



<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
   <soapenv:Header/>
   <soapenv:Body>
      <soapenv:Fault>
         <soapenv:Code>
            <soapenv:Value>env:Sender</soapenv:Value>
         </soapenv:Code>
         <soapenv:Reason>
            <soapenv:Text xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace">Unknown Error :(</soapenv:Text>
         </soapenv:Reason>
         <soapenv:Detail>
            <EchoServiceError>Echo service failed </EchoServiceError>
         </soapenv:Detail>
      </soapenv:Fault>
   </soapenv:Body></soapenv:Envelope>

This will not yield an operation not found error, but a Echo service failed error as your service expects a payload. You can respond with a dummy payload instead of calling the axis2_echo_echo() method in the echo_skeleten.c file of the echo service.

Also, it seems that if addressing is disengaged, Axis2/C Client wont add the SOAP action to the Content-Type header when using SOAP 1.2. Isn't this a bug?

Regards,
Senaka

      was (Author: senakafdo):
    Hi Dimuthu and Michael,
Just being curious about what you said, I tried out changing the uri of the request, to include the operation at the end, instead of the operation in the action field of the Content-Type (MIME) header, I used urn:operation, and IT WORKED.

Therefore, this is not a bug. I think you may be missing something in your services.xml or you may be calling an incorrect operation.

We do have four dispatchers invoked along the path of execution.
1. Request uri based
2. WS-Addressing based
3. SOAP action based
4. SOAP message body based

All four can be found inside the src/core/engine folder.

Technically, you should not be having any issue in calling getStatus in DAQStatus.

For an example, you can test this feature using the echo client.

This is what should be done.
1. Change the address to http://localhost:9090/axis2/services/echo/echoString
2. Replace options set action with axis2_options_set_action(options, env, "urn:echoString");
3. Send NULL payload: axis2_svc_client_send_receive(svc_client, env, NULL);
4. Disengage addressing in axis2.xml

The exchanged payload would look like,

Request
------------
POST /axis2/services/echo/echoString HTTP/1.1

User-Agent: Axis2/C

Content-Length: 125

Content-Type: application/soap+xml;charset=UTF-8

Host: 127.0.0.1:9090



<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
   <soapenv:Header/>
   <soapenv:Body/></soapenv:Envelope>

Response
---------------
HTTP/1.1 500 Internal Server Error

Content-Type: application/soap+xml;charset=UTF-8

Content-Length: 471



<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
   <soapenv:Header/>
   <soapenv:Body>
      <soapenv:Fault>
         <soapenv:Code>
            <soapenv:Value>env:Sender</soapenv:Value>
         </soapenv:Code>
         <soapenv:Reason>
            <soapenv:Text xml:lang="en" xmlns:xml="http://www.w3.org/XML/1998/namespace">Unknown Error :(</soapenv:Text>
         </soapenv:Reason>
         <soapenv:Detail>
            <EchoServiceError>Echo service failed </EchoServiceError>
         </soapenv:Detail>
      </soapenv:Fault>
   </soapenv:Body></soapenv:Envelope>

This will not yield an operation not found error, but a Echo service failed error as your service expects a payload. You can respond with a dummy payload instead of calling the axis2_echo_echo() method in the echo_skeleten.c file of the echo service.

Also, it seems that if addressing is disengaged, Axis2/C Client wont add the SOAP action to the Content-Type header when using SOAP 1.2. Isn't this a bug?

Regards,
Senaka
  
> SOAPAction dispatching
> ----------------------
>
>                 Key: AXIS2C-837
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-837
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: build system (Unix/Linux)
>         Environment: Suse Linux 9.1, gcc 3.3, Axis Java nightly build
>            Reporter: Michael Sutter
>            Priority: Minor
>             Fix For: Current (Nightly)
>
>
> By accessing a c webservice with no parameters with a Java client to dispatching of the sent SOAP Action is not working. The Java client always get a Operation Not Found exception. The SOAP requests looks like this:
> POST /axis2/services/DAQStatus/getStatus HTTP/1.1
> Content-Type: application/soap+xml; charset=UTF-8; action="urn:getStatus"
> User-Agent: Axis2
> Host: 192.168.12.100:9090
> Transfer-Encoding: chunked
> 93
> <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body /></soapenv:Envelope>
> 0
> So the SOAP Action is sent. To fix this in the client simply add the method to call to the request uri (shown above getStatus). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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