[ http://issues.apache.org/jira/browse/AXISCPP-914?page=all ]
Franz Fehringer updated AXISCPP-914:
------------------------------------
Attachment: PegsPortType.cpp
t_ErrorResponse.cpp
> 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
