Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <1185865150.1256287199382.JavaMail.jira@brutus>
Date: Fri, 23 Oct 2009 08:39:59 +0000 (UTC)
From: "Francois Mireaux (JIRA)" <jira@apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Commented: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite
 previously set error status
In-Reply-To: <1162507722.1255584271275.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769134#action_12769134 ] 

Francois Mireaux commented on AXIS2C-1402:
------------------------------------------

Modification 5 in the above patch was made for Axis2c notify sample. 

Digging more deeply, I found that en status was set in axis2_addr_out_handler_invoke (addr_out_handler.c) by the call : 

        axis2_addr_out_handler_add_to_soap_header(env, epr_reply_to, AXIS2_WSA_REPLY_TO, 
            soap_header, addr_ns); 

where "epr_reply_to" was NULL in that case, because the above"if (!epr_reply_to) " don't set epr_reply_to when "none" and "anonymous" are FALSE. 

So either we need to test again epr_reply_to or to allways define it : for the time being, I am not able to decide what to do. 

That shows that, if modification of AXIS2_PARAM_CHECK macro is good for code safety, a significant work must be done to track all problems hidden by the previous macro writing. 


> AXIS2_PARAM_CHECK overwrite previously set error status
> -------------------------------------------------------
>
>                 Key: AXIS2C-1402
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1402
>             Project: Axis2-C
>          Issue Type: Bug
>    Affects Versions: 1.6.0
>            Reporter: S.Uthaiyashankar
>            Assignee: S.Uthaiyashankar
>             Fix For: Next Version
>
>         Attachments: axis2_param_check.patch
>
>
> When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); 
> check the macro definition:
> #define AXIS2_PARAM_CHECK(error, object, error_return)                  \
>     if (!object)                                                        \
>     {                                                                   \
>         AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
>         AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE);              \
>         return error_return;                                            \
>     }                                                                   \
>     else                                                                \
>     {                                                                   \
>         AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);              \
>     }
> Ideally, if PARAM_CHECK is success, it should not touch error status code. 
> This macro is a problem when sending soap faults from generated code. To send faults from generated code, we have to set the error status inside service logic and it will be checked by the engine to create soap fault. However, after setting error status, there are several generated codes doing AXIS2_PARAM_CHECK and hence overwriting the status code. 

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