axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Darroch (JIRA)" <>
Subject [jira] Commented: (AXIS2C-328) unable to return custom SOAP faults
Date Thu, 02 Nov 2006 17:43:19 GMT
    [ ] 
Chris Darroch commented on AXIS2C-328:

See the most recent set of patches I'm attching now to AXIS2C-380.  These
enable SOAP faults to be returned properly in httpd+mod_axis2 as well as the

The key changes are:

1) apache2_worker.c needs to set request->status to
HTTP_INTERNAL_SERVER_ERROR  but return OK; otherwise httpd
will supply its own ErrorDocument reponse.

2) engine.c and raw_xml_in_out_msg_recv.c both need to create SOAP
faults in a better manner, using appropriate XML namespace prefixes and
fault code strings.

3) raw_xml_in_out_msg_recv.c needs to return AXIS2_SUCCESS in the case
where it's generated a correct SOAP fault reponse, as noted in the initial bug

4) disp_checker.c needs to set the error code to
 AXIS2_ERROR_SVC_OR_OP_NOT_FOUND when handling those

> unable to return custom SOAP faults
> -----------------------------------
>                 Key: AXIS2C-328
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: core/receivers, code generation, wsdl2c tool
>    Affects Versions: Current (Nightly), 0.93
>            Reporter: Chris Darroch
> Thanks, BTW, for the tcpmon tool -- very helpful!
> I have a need to return custom SOAP fault messages from an Axis2/C server.  This turns
out to require some patches in a few places.  First, the code generated by the w2c tool always
calls a local on_fault handler, named axis2_svc_skel_foo_on_fault() in the axis2_svc_skel_foo.c
file.  This function, as generated by w2c, creates a <fault> element and returns it
in the SOAP body.
> Changing axis2_svc_skel_foo_on_fault() to simply return NULL instead allows the
> axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() function in
> modules/core/receivers/raw_xml_in_out_msg_recv.c to recognize that no body element
> has been returned, and create a SOAP fault instead.
> The actual business logic that one fills into the axis2_skel_foo.c file can then simply
> do the following:
> axis2_skel_foo_Foo(...) {
>     AXIS2_ERROR_SET_ERROR_NUMBER(env->error,
>                                  AXIS2_ERROR_FOO);
>     return NULL;
> }
> This almost works, and axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync()
> now recognizes the fault condition and calls axiom_soap_fault_create_default_fault()
> to create the SOAP fault element.  Good, except that it then returns AXIS2_FAILURE,
> so that its caller, axis2_raw_xml_in_out_msg_recv_receive_sync() in
> modules/core/receivers/msg_recv.c, then does this:
>     status = AXIS2_MSG_RECV_INVOKE_IN_OUT_BUSINESS_LOGIC_SYNC(msg_recv, env,
>             msg_ctx, out_msg_ctx);
>     if(AXIS2_SUCCESS != status)
>     {
>         axis2_core_utils_reset_out_msg_ctx(env, out_msg_ctx);
>         AXIS2_MSG_CTX_FREE(out_msg_ctx, env);
>         return status;
>     }
> which destroys the nice SOAP fault and returns an empty body element instead to the client!
> My current patch is to have axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync()
return AXIS2C_SUCCESS instead -- this makes sense to me, because although an fault
> condition has been detected, the function has successfully handled it by creating
> the SOAP fault element.  Here's the patch:
> ====================================
> --- modules/core/receivers/raw_xml_in_out_msg_recv.c.orig       2006-10-07 13:31:17.801951262
> +++ modules/core/receivers/raw_xml_in_out_msg_recv.c    2006-10-07 13:31:36.094847670
> @@ -325,7 +325,7 @@
>      else if (soap_fault)
>      {
>          AXIS2_MSG_CTX_SET_SOAP_ENVELOPE(new_msg_ctx, env, default_envelope);
> -        status = AXIS2_FAILURE; /* if there is a failure we have to return a failure
code */
> +        status = AXIS2_SUCCESS;
>      }
>      else
>      {

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message