[
https://issues.apache.org/jira/browse/AXIS2C-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brice André updated AXIS2C-1494:
--------------------------------
Priority: Minor (was: Blocker)
Issue Type: Improvement (was: Bug)
Summary: Response received from the server is partially erased when
non-ascii characters present in xml tags (was: Partial response received from
the served)
OK, I investigated furthermore this problem and I found what was causing the
trouble.
The mistake was in my code : I was generating string content that contained
non-ascii characters. I suppose I must encode this content before providing it
to the data-binding functions.
I changed the description of this bug because it is not an error in the Axis2c
engine, but I did not close it because I am not sure the behaviour of the
engine in such a situation is the proper one.
Maybe would it be more "user-friendly" if the caller was warned that the
provided string contains invalid characters ?
Maybe would it also be safer if the low-level layers of Axis2c did not drop
everything located after an invalid character. Dropping everything or only the
invalid character would maybe be better options ?
> Response received from the server is partially erased when non-ascii
> characters present in xml tags
> ---------------------------------------------------------------------------------------------------
>
> Key: AXIS2C-1494
> URL: https://issues.apache.org/jira/browse/AXIS2C-1494
> Project: Axis2-C
> Issue Type: Improvement
> Environment: Windows 7, pre-built version of Axis2-C for MSVC, client
> compiled with Mingw
> Reporter: Brice André
> Priority: Minor
> Attachments: ClientLog.txt, ClientsRequests.wsdl, wireshark_trace.pcap
>
>
> I wrote a small web service by implementing the server part in Java by using
> Axis2, and by implementing the client in C++ by using Axis2-C.
> The web service is composed of two operations. The operation named
> 'SynchroniseMessages' has, as output, the type "SynchroniseMessagesResponse"
> which is composed of one element of type "ThreadMessage_t", but with
> multiplicity 0..*.
> My problem is that my server is sending 6 elements of type "ThreadMessage_t"
> but, my client is only receiving the first 4 elements.
> In order to investigate the problem, I checked with Wireshark the content of
> messages exchanged between the client and the server. The packet containing
> the response from the server contains the six elements. So, I am pretty sure
> the problem is located in the client.
> I added log in the generated code to check if the data binding was not
> causing the error. I printed the result of the function
> 'axis2_svc_client_send_receive_with_op_qname', located in the generated
> 'axis2_stub_op_ClientsRequests_SynchroniseMessages' function (located in the
> generated file named 'axis2_stub_ClientsRequests.c'). In order to log the
> result, I added the following line of code :
> printf("ret_node : %s\n", axiom_node_to_string(ret_node,env));
> I copy-pasted the log just below, but we can see that only the 4 first
> elements are retrieved. So, my conclusion would be that the problem is not
> located in the data-binding part of the client, but in lower layers of the
> code.
> I am completely blocked because, as I am not able to recompile the axis2c
> engine (I am using Mingw and no makefile exists for this compiler), I am not
> able to investigate furthermore this problem.
> Best Regards,
> Brice
> PS : I joined to this bug the WireShark log, the WSDL file describing my web
> service, as well as the log incoming from client
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
