axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Dick (JIRA)" <axis-c-...@ws.apache.org>
Subject [jira] Commented: (AXISCPP-914) fault/exception/error handling flawed
Date Wed, 01 Mar 2006 22:32:13 GMT
    [ http://issues.apache.org/jira/browse/AXISCPP-914?page=comments#action_12368383 ] 

Adrian Dick commented on AXISCPP-914:
-------------------------------------

The Fault model is a known weak area.  Sometime ago I made a proposal to re-work the model,
including extending support for SOAP 1.2   (the proposal can be seen here: http://marc.theaimsgroup.com/?l=axis-c-dev&m=111640463326474&w=2
)

Alas, this piece of work has yet not been undertaken.

However, I have recently done a little work on improving memory management within Faults (although
there is bound to be more that can be done).

> 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: PegsPortType.cpp, t_ErrorResponse.cpp, 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


Mime
View raw message