[
https://issues.apache.org/jira/browse/AXIS2C-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561179#action_12561179
]
Bill Mitchell commented on AXIS2C-834:
--------------------------------------
Lahiru, AXIS2C-891 identified a guththila problem with default namespaces in
received messages; this defect describes a problem in guththila sending
messages when a default namespace has been identified. I reverted to the
checked-in versions of the guththila_xml_writer and
guththila_xml_writer_wrapper. As you can see from the crash below, the problem
I described still exists.
At the time I wrote this, ADB code generation was not working for me. With
changes to the ADB code generation since this defect was written, it has become
a little more work to reproduce the problem. The generated stubs assign a
prefix "n" to the namespace from the WSDL, so the default namespace case does
not arise directly with them. To verify the behavior of the underlying code, I
modified the stub to use axiom_element_declare_default_namespace() to assign
the URI of the namespace (see AXIS2C-927), commenting out the generated stub
code that creates a namespace hash and creates a namespace with a prefix value
"n". As you can see from the traceback below, when
guththila_xml_writer_wrapper_write_namespace() is called with a prefix pointer
of 0, a seg fault occurs in guththila_write_namespace.
> msvcr80d.dll!strlen(unsigned char * buf=0x0272d0fc) Line 81 Asm
guththila.dll!guththila_write_namespace(guththila_xml_writer_s *
wr=0x027e43d8, char * prefix=0x00000000, char * uri=0x027e8f90, const
axutil_env * env=0x0172b450) Line 794 + 0x9 bytes C
axis2_parser.dll!guththila_xml_writer_wrapper_write_namespace(axiom_xml_writer
* writer=0x027e21c8, const axutil_env * env=0x0172b450, char *
prefix=0x00000000, char * namespace_uri=0x027e8f90) Line 539 C
axis2_parser.dll!axiom_xml_writer_write_namespace(axiom_xml_writer *
writer=0x027e21c8, const axutil_env * env=0x0172b450, char * prefix=0x00000000,
char * namespace_uri=0x027e8f90) Line 173 C
axiom.dll!axiom_output_write(axiom_output * om_output=0x027eafb8, const
axutil_env * env=0x0172b450, axiom_types_t type=AXIOM_NAMESPACE, int
no_of_args=2, ...) Line 532 + 0x17 bytes C
axiom.dll!axiom_namespace_serialize(axiom_namespace *
om_namespace=0x027e8970, const axutil_env * env=0x0172b450, axiom_output *
om_output=0x027eafb8) Line 194 + 0x23 bytes C
axiom.dll!axiom_element_serialize_start_part(axiom_element *
om_element=0x027e8340, const axutil_env * env=0x0172b450, axiom_output *
om_output=0x027eafb8, axiom_node * ele_node=0x027e7d88) Line 805 + 0x11 bytes
C
axiom.dll!axiom_node_serialize(axiom_node * om_node=0x027e7d88, const
axutil_env * env=0x0172b450, axiom_output * om_output=0x027eafb8) Line 383 +
0x18 bytes C
axiom.dll!axiom_soap_envelope_serialize(axiom_soap_envelope *
soap_envelope=0x027e5180, const axutil_env * env=0x0172b450, axiom_output *
om_output=0x027eafb8, int cache=0) Line 330 C
axis2_http_sender.dll!axis2_libcurl_send(axis2_libcurl *
data=0x0172ec40, axiom_output * om_output=0x027eafb8, const axutil_env *
env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8, axiom_soap_envelope *
out=0x027e5180, const char * str_url=0x0172b6a8, const char *
soap_action=0x027ea180) Line 207 C
axis2_http_sender.dll!axis2_libcurl_http_send(axis2_libcurl *
curl=0x0172ec40, axis2_http_sender * sender=0x027da9b0, const axutil_env *
env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8, axiom_soap_envelope *
out=0x027e5180, const char * str_url=0x0172b6a8, const char *
soap_action=0x027ea180) Line 2355 C
axis2_http_sender.dll!axis2_http_transport_sender_write_message(axis2_transport_sender
* transport_sender=0x0172ebe8, const axutil_env * env=0x0172b450,
axis2_msg_ctx * msg_ctx=0x027e7fc8, axis2_endpoint_ref * epr=0x0172b4a8,
axiom_soap_envelope * out=0x027e5180, axiom_output * om_output=0x027eafb8)
Line 726 + 0x24 bytes C
axis2_http_sender.dll!axis2_http_transport_sender_invoke(axis2_transport_sender
* transport_sender=0x0172ebe8, const axutil_env * env=0x0172b450, axis2_msg_ctx
* msg_ctx=0x027e7fc8) Line 310 + 0x1d bytes C
axis2_engine.dll!axis2_engine_send(axis2_engine * engine=0x027e9de0,
const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8) Line
179 C
axis2_engine.dll!axis2_op_client_two_way_send(const axutil_env *
env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8) Line 1134 + 0x11 bytes C
axis2_engine.dll!axis2_op_client_execute(axis2_op_client *
op_client=0x027e34e8, const axutil_env * env=0x0172b450, const int block=1)
Line 483 + 0xd bytes C
axis2_engine.dll!axis2_svc_client_send_receive_with_op_qname(axis2_svc_client *
svc_client=0x01755028, const axutil_env * env=0x0172b450, const axutil_qname *
op_qname=0x027ea260, const axiom_node * payload=0x027e7d88) Line 807 C
mysqld.exe!axis2_stub_op_FramewareService_browse(axis2_stub *
stub=0x0172b718, const axutil_env * env=0x0172b450, adb_browse *
_browse=0x027e4df0) Line 829 + 0x18 bytes C
...
So you can see that problem(1) in my issue description still applies. You
should be able to verify by code inspection that problem (2) and problem (3)
still apply as well. I am able to force the path through these by modifying
the generated stub code to specify a prefix of NULL/"" instead of "n" when
declaring the namespace explicitly. After applying the suggested fix to
problem (3), I still see the malformed XML described in problem (2) above.
> guththila_xml_writer has problems with default namespace
> --------------------------------------------------------
>
> Key: AXIS2C-834
> URL: https://issues.apache.org/jira/browse/AXIS2C-834
> Project: Axis2-C
> Issue Type: Bug
> Components: guththila, xml/parser
> Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila parser,
> libcurl transport
> Reporter: Bill Mitchell
> Attachments: guththila_xml_writer_diff,
> guththila_xml_writer_wrapper_diff
>
>
> The guththila xml writer appears to have several problems related to the
> default namespace. These appear when attempting to use the ADB stubs for the
> elements in the SOAP request messages, as the Axis data bindings fill in the
> default namespace from the WSDL.
> (1) In guththila_xml_writer_wrapper, guththila_xml_writer_wrap_namespace()
> has a comment indicating that the prefix is null on the default namespace.
> Yet it goes ahead and calls guththila_write_namespace() which requires both a
> prefix and a namespace URI.
> (2) In guththila_xml_wrapper.c, the routine
> guththila_write_start_element_with_namespace() does not understand the
> default namespace. It searches the table of namespaces to determine the
> prefix that goes with this namespace. If the namespace is not found, no XML
> is generated, so no element is started although the outer code assumes it is.
> This results in malformed XML as below:
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
> <soapenv:Header></soapenv:Header>
> <soapenv:Body name="customer" exemplarHandle="master"
> xmlns="http://frameware.xcentrisity.com/services/";></soapenv:Body>
> </soapenv:Envelope></
> Yes, the trailing </ is not a typo. When the XML writer tries to close off 3
> elements in the stack without having started one of the elements, this is the
> outcome.
> (3) After fixing the above problems, I discovered that the generated XML for
> the element inside the SOAP Body incorrectly had the URI of the namespace as
> the name of the element, rather than the name itself. I.e., the message
> contained a structure like:
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
> <soapenv:Header></soapenv:Header>
> <soapenv:Body>
> <http://frameware.xcentrisity.com/services/ name="customer"
> exemplarHandle="master"
> xmlns="http://frameware.xcentrisity.com/services/";></http://frameware.xcentrisity.com/services/>
> </soapenv:Body>
> </soapenv:Envelope>
> The problem is that
> guththila_xml_writer_wrapper_start_element_with_namespace() is not flipping
> the order of the parameters as is correctly done in
> guththila_xml_writer_wrapper_start_element_with_namespace_prefix().
--
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]
