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: <428984510.1137781062379.JavaMail.jira@ajax.apache.org>
Date: Fri, 20 Jan 2006 19:17:42 +0100 (CET)
From: "Franz Fehringer (JIRA)" <axis-c-dev@ws.apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Updated: (AXISCPP-914) fault/exception/error handling flawed
In-Reply-To: <1970162141.1137780941964.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/AXISCPP-914?page=all ]

Franz Fehringer updated AXISCPP-914:
------------------------------------

    Attachment: vakanz.wsdl
                vakanz.xsd

> fault/exception/error handling flawed
> -------------------------------------
>
>          Key: AXISCPP-914
>          URL: http://issues.apache.org/jira/browse/AXISCPP-914
>      Project: Axis-C++
>         Type: Bug
>   Components: Client - Stub
>     Versions: 1.6 Alpha
>  Environment: WIN2KSP4 JDK1.5.0_06 MSVC6SP6
>     Reporter: Franz Fehringer
>  Attachments: vakanz.wsdl, vakanz.xsd
>
> fault/exception/error handling seems to be flawed in several respects (in what follows i refer to my attached example).
> First the intention of the WSDL/XSD writers clearly was to expect an ErrorResponse element inside the soap:faultdetail for the error scenario of all three requests (and i think they are right so).
> The Axis generated code instead looks for LoginFault, LogoutFault and SearchRoomsFault.
> Second there seem to be problems with memory management.
> I get user defined breakpoints and/or access violations at (all in PegsPortType.cpp)
> throw fault; // line 588
> delete [] const_cast<char*>(detail); // lines 615,720,879
> The const_cast as well as the interplay between assignment and delete operations generally look fishy too me.
> In my investigations i stumbled over the generated t_ErrorResponse (derived from SoapFaultException) copy constructor.
> The base class is not copied over there.
> More to follow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira