[jira] Commented: (AXIS2C-1046) mod_axis2.dll load fails on Win XP SP2 (Japanese edition)
[ https://issues.apache.org/jira/browse/AXIS2C-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576235#action_12576235 ] Bill Mitchell commented on AXIS2C-1046: --- Hi Senaka, I would hate for someone to read your comment too broadly, as the Axis2C passing of Unicode in a char * as UTF-8 works fine for many applications. I have done some light testing passing UTF-8 data from the application to the server through Axis2C without any problem. So it would seem in this particular situation, the problem must lie in the Apache to mod_axis2 side, or in the Axis2C interface to the OS, or both. Do you know, does Apache pass its Unicode data only in wide-char (UCS-2) format? I believe Windows XP actually records filenames in UTF-8; do the Windows file APIs, e.g., open(), support only ASCII data in a char * filenames? They might accept UTF-8 filenames. This might be an entirely different issue, if Apache passes the filename in the OEM character set, e.g, SJIS, etc., that is wide char but not Unicode. Regards, Bill mod_axis2.dll load fails on Win XP SP2 (Japanese edition) - Key: AXIS2C-1046 URL: https://issues.apache.org/jira/browse/AXIS2C-1046 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: 1.3.0 Environment: Win XP SP2 (Japanese edition) Reporter: Ikeda Apache fails to initialize and abort in following circumstance: - when Apache need to load mod_Axis2.dll - and if its absolute path contains non-ascii characters (2 byte Japanese) we confronted such thing when running Apache in Win XP Japanese -- 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]
[jira] Commented: (AXIS2C-1046) mod_axis2.dll load fails on Win XP SP2 (Japanese edition)
[ https://issues.apache.org/jira/browse/AXIS2C-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576288#action_12576288 ] Bill Mitchell commented on AXIS2C-1046: --- Exactly. A global fix will require the wchar approach. And a global fix will allow support for other character encodings in the messages, e.g., UTF-16 and byte-order-markers and all that implies. I just wanted to raise the question, whether there is something going on here such that some local solution might work. Or, alternatively, that something is going on here in the Japanese XP case that is not covered just by adding wide-char (UCS-2) support. My test environment is Windows US, where many things happen to work using UTF-8, and I'm focused on the client side, not Axis under Apache server, so I don't have a good test bed to investigate this in detail. Ikeda, to ensure that whatever fix is implemented covers your situation, you might want to investigate this in a little more detail to see what is happening at each level. Of course, as is implied in your problem description, you might already have a work around of placing the mod_axis2.dll in a path that does not use Japanese characters. mod_axis2.dll load fails on Win XP SP2 (Japanese edition) - Key: AXIS2C-1046 URL: https://issues.apache.org/jira/browse/AXIS2C-1046 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: 1.3.0 Environment: Win XP SP2 (Japanese edition) Reporter: Ikeda Apache fails to initialize and abort in following circumstance: - when Apache need to load mod_Axis2.dll - and if its absolute path contains non-ascii characters (2 byte Japanese) we confronted such thing when running Apache in Win XP Japanese -- 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]
[jira] Commented: (AXIS2C-1040) Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
[ https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574719#action_12574719 ] Bill Mitchell commented on AXIS2C-1040: --- Agreed, Senaka, I'm easy. You're probably right that there is no other purpose for AXIS2_EXPORT except for these DLL entry points, so making it be empty in the header file in the static build works just as well as providing conditional compilation in the modules themselves. I did not verify if there were other uses when I wrote my comments above, just the uses Frank pointed out. Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build - Key: AXIS2C-1040 URL: https://issues.apache.org/jira/browse/AXIS2C-1040 Project: Axis2-C Issue Type: Bug Components: util Reporter: Frank Huebbers I have seen a few places where the typedef AXIS2_EXPORT is used instead of AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels: - axis2_msg_recv.h - msg_recv.c - raw_xml_in_out_msg_recv.c - svr_callback.c - mod_addr.c - http_transport_sender.c - http_receiver.c - http_svr_thread.c - tcp_transport_sender.c - tcp_svr_thread.c - tcp_receiver.c Note that the definitions are correct in the header files. Frank -- 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]
[jira] Commented: (AXIS2C-1040) Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
[ https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574045#action_12574045 ] Bill Mitchell commented on AXIS2C-1040: --- Looking at the exports from the Windows DLLs, I suspect that the AXIS2_EXPORT declaration is required for the dynamic link. The likely fix is to ensure that the AXIS2_EXPORT declaration is present only in the non-AXIS2_STATIC_DEPLOY case by including it within the #ifndef. Such ifndef declarations are already present in http_transport_sender.c; the AXIS2_EXPORT there just lies outside the ifndef. Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build - Key: AXIS2C-1040 URL: https://issues.apache.org/jira/browse/AXIS2C-1040 Project: Axis2-C Issue Type: Bug Components: util Reporter: Frank Huebbers I have seen a few places where the typedef AXIS2_EXPORT is used instead of AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels: - axis2_msg_recv.h - msg_recv.c - raw_xml_in_out_msg_recv.c - svr_callback.c - mod_addr.c - http_transport_sender.c - http_receiver.c - http_svr_thread.c - tcp_transport_sender.c - tcp_svr_thread.c - tcp_receiver.c Note that the definitions are correct in the header files. Frank -- 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]
[jira] Commented: (AXIS2C-1015) In axutil_uri, a reference is returned, where a duplicated string should be.
[ https://issues.apache.org/jira/browse/AXIS2C-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573357#action_12573357 ] Bill Mitchell commented on AXIS2C-1015: --- Although I've not researched exactly how the axutil_uri_get_xxx accessors are used, it appears that generally throughout Axis2C the _get_ accessors return axis2_char_t * or similar references without a const declaration, and with no intention of allowing the caller to modify the indicated string. Consider, for example, axiom_namespace_get_prefix in axiom_namespace.h. Changing every such interface to return a duplicate will introduce a lot of overhead and will mean that the callers must take ownership and free the associated memory. It would be better to perform a general overhaul of the interfaces to add const to the declarations, although such a change, too, will naturally propagate throughout the callers' code as well. In axutil_uri, a reference is returned, where a duplicated string should be. Key: AXIS2C-1015 URL: https://issues.apache.org/jira/browse/AXIS2C-1015 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: 1.3.0 Reporter: Senaka Fernando Assignee: Senaka Fernando In axutil_uri, a reference is returned, where a duplicated string should be. This is because we return axis2_char_t * rather than const axis2_char_t *. However, a user is expected to be able modify what is returned, according to current api, and thus we must return a cloned copy of the actual string. -- 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]
[jira] Resolved: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-675. -- Resolution: Fixed Fix Version/s: 1.3.0 Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell Fix For: 1.3.0 Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt While working on the routine to copy a node tree, I found it needed the same worker routines as did axiom_node_detach to manage namespaces declared in a parent of the subtree being copied/detached. As well, looking at these routines they knew a lot more about the internals of elements than they had to do with the node structure. So, this third version moves the worker routines into om_element.c where they fit a little better. Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Assigned: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reassigned AXIS2C-675: Assignee: Bill Mitchell Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt I've updated the attached diff to include two additional changes. (1) Detach is now included as one of the actions of axiom_node_free, when the node still has a parent. All the appropriate points in Axis have been changed to take advantage of this. This allows the free process to perform an internal detach that avoids preserving the integrity of namespace references. (2) When a node is detached, it determines all the namespaces in its parents that may be inscope for it or its children. The new action is then to scan the subtree to determine which of these namespaces are actually referenced in the subtree, and to redeclare only the namespaces that are actually referenced. Senaka, I think that (2) resolves most of your concern about increasing the size of the payloads with unused namespace declarations, at the cost of scanning the subtree during detach. I do have a clever idea of something that could be done during attach, to further address your payload size concern without modifying all the namespace reference values. We could promote the declared namespaces up the tree to a higher parent, detecting if the namespace has already been declared at the higher node. This would eliminate multiple declarations when multiple detached subtrees are attached to a new tree. I'm reluctant to implement this, though, as it would make no difference in the case with which I'm familiar of the generated adb stubs. The adb classes serialize the pieces of the request message directly, without first collecting them into one tree via attach, so repetitive namespace declarations in multiple passed request objects would not be removed. Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Issue Comment Edited: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570667#action_12570667 ] wtmitchell3 edited comment on AXIS2C-675 at 2/20/08 4:29 AM: --- I've updated the attached diff to include two additional changes. (1) Detach is now included as one of the actions of axiom_node_free, when the node still has a parent. All the appropriate points in Axis have been changed to take advantage of this. This allows the free process to perform an internal detach that avoids preserving the integrity of namespace references. (2) When a node is detached, it determines all the namespaces in its parents that may be inscope for it or its children. The new action is then to scan the subtree to determine which of these namespaces are actually referenced in the subtree, and to redeclare only the namespaces that are actually referenced. Senaka, I think that (2) resolves most of your concern about increasing the size of the payloads with unused namespace declarations, at the cost of scanning the subtree during detach. I do have a clever idea of something that could be done during attach, to further address your payload size concern without modifying all the namespace reference values. We could promote the declared namespaces up the tree to a higher parent, detecting if the namespace has already been declared at the higher node. This would eliminate multiple declarations when multiple detached subtrees are attached to a new tree. I'm reluctant to implement this, though, as it would make no difference in the case with which I'm familiar of the generated adb stubs. The adb classes serialize the pieces of the request message directly, without first collecting them into one tree via attach, so repetitive namespace declarations in multiple passed request objects would not be removed. This diff is relative to the head. I will be working on the discussed axiom_node_copy method separately so it can be on a branch. was (Author: wtmitchell3): I've updated the attached diff to include two additional changes. (1) Detach is now included as one of the actions of axiom_node_free, when the node still has a parent. All the appropriate points in Axis have been changed to take advantage of this. This allows the free process to perform an internal detach that avoids preserving the integrity of namespace references. (2) When a node is detached, it determines all the namespaces in its parents that may be inscope for it or its children. The new action is then to scan the subtree to determine which of these namespaces are actually referenced in the subtree, and to redeclare only the namespaces that are actually referenced. Senaka, I think that (2) resolves most of your concern about increasing the size of the payloads with unused namespace declarations, at the cost of scanning the subtree during detach. I do have a clever idea of something that could be done during attach, to further address your payload size concern without modifying all the namespace reference values. We could promote the declared namespaces up the tree to a higher parent, detecting if the namespace has already been declared at the higher node. This would eliminate multiple declarations when multiple detached subtrees are attached to a new tree. I'm reluctant to implement this, though, as it would make no difference in the case with which I'm familiar of the generated adb stubs. The adb classes serialize the pieces of the request message directly, without first collecting them into one tree via attach, so repetitive namespace declarations in multiple passed request objects would not be removed. Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Assignee: Bill Mitchell Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt The attached diff.txt implements a change to attach all the namespaces in scope on an element node being detached to the element, so that the detached node and all its children will still have valid namespace references even if the former parent tree is freed. Beyond the obvious change to detach to preserve the namespace, it required cleaning up several places in om_element that would allow an attribute to be attached without the namespace structure it pointed to being declared at the element or one of its parents. The former code seemed to accept that the namespace uri or prefix was declared somewhere, without requiring that the very same structure be used. Testing also revealed another anomaly. Now that guththila behaves like libxml and parses xml:id attributes, with this change the xml: namespace would be preserved in the detached node. When that structure was subsequently serialized and passed to a remote system not using Axis, in particular a system using the Microsoft xml parser, this unnecessary but allowed xml namespace declaration is diagnosed as an error. So we should just not emit it on output. Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon Attachments: diff.txt When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Created: (AXIS2C-987) Generated adb stubs do not support attributes with namespaces
Generated adb stubs do not support attributes with namespaces
-
Key: AXIS2C-987
URL: https://issues.apache.org/jira/browse/AXIS2C-987
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: 1.2.0
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
For the attributes defined in the wsdl, the generated stub classes require that
the namespace prefix be omitted from the attribute. If a prefix is attached to
the attribute, the generated stub fails to find the attribute.
For example, the following is the code that looks for a handle attribute:
parent_attri = NULL;
attrib_text = NULL;
if(attribute_hash)
{
axutil_hash_index_t *hi;
void *val;
const void *key;
for (hi = axutil_hash_first(attribute_hash, env); hi; hi
= axutil_hash_next(env, hi))
{
axutil_hash_this(hi, key, NULL, val);
if(!strcmp((axis2_char_t*)key, handle))
{
parent_attri = (axiom_attribute_t*)val;
break;
}
}
}
if(parent_attri)
{
attrib_text = axiom_attribute_get_value(parent_attri, env);
}
else
{
/* this is hoping that attribute is stored in handle,
this happnes when name is in default namespace */
attrib_text =
axiom_element_get_attribute_value_by_name(parent_element, env, handle);
}
The strcmp compares the attribute key against the string handle, but the
attribute key is the qname string from the attribute.
Obviously the robust fix is to ensure the attribute localname matches, and that
the namespace uri matches if present.
The quick fix is to replace the strcmp with something like:
if(!strcmp(axiom_attribute_get_localname((axiom_attribute_t *)val, env),
handle))
I suspect this quick fix is not the longterm fix, as it accepts an attribute
with a different uri than that expected. It appears to me that the non-uri
case is handled later in the code by the
axiom_element_get_attribute_value_by_name call. The hash search loop was
probably intended to compare against the attribute qname, but the qname logic
was may have been removed temporarily or not fully implemented to solve other
issues with the default namespace or multiple namespaces in the wsdl.
--
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]
[jira] Reopened: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-675: -- This problem has been encountered again recently, and it appears to me there is a real issue in axiom_node_detach and how it is used. Consider the case of a SOAP response message in which the server declared the namespaces at one of the outer elements. Where a wsdl declares an element of type any, not knowing the underlying structure, the generated adb classes detach the node and its subtree and makes the tree available to the client app. The client app may choose to retain the response structure and the returned object tree for later use. Yet the upper levels of the om will be discarded when the SOAP response message is discarded upon the next request through the service client. And, thus, Axis will free the namespaces underneath the adb objects. It hardly seems fair to place the responsibility on the creator of the tree not to release the namespaces underneath the detached node, when the tree is created as the SOAP message is parsed, and the location of the xml namespace declaration in the message is determined by the other side of the exchange. An alternative fix is to re-declare the namespaces on the node being detached, to ensure that it and its children remain valid regardless of what happens to its former parent tree. Re-declaring the namespaces will cause the ref counts in the namespaces to be incremented, and thus the namespace structures will be retained until both the former parent tree and the detached node tree are released. Detach node does not handle namespaces -- Key: AXIS2C-675 URL: https://issues.apache.org/jira/browse/AXIS2C-675 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Jamie Lyon When detaching a node from a parent, if the current node or any of it's children have any namespaces declared in it's parent or above, when the node is detached, and the parent freed, any namespace references are lost. -- 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]
[jira] Commented: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568414#action_12568414
]
Bill Mitchell commented on AXIS2C-791:
--
Senaka, following your suggestion, I restored the AXIS2_ERROR_SET calls in svn
rev 627226.
On in-out message flow that fails with no response, no error code or
misleading error code is returned, expected error number 3.
--
Key: AXIS2C-791
URL: https://issues.apache.org/jira/browse/AXIS2C-791
Project: Axis2-C
Issue Type: Bug
Components: core/clientapi
Affects Versions: 1.1.0
Environment: Windows XP, Visual Studio 2005
Reporter: Bill Mitchell
Assignee: Bill Mitchell
Priority: Minor
Fix For: 1.3.0
Attachments: diff.txt
If a blocking I/O is requested for an in-out message exchange and no response
is received, axis2_svc_client_send_receive et.al. return a zero response
pointer. But one would expect the errno variable to contain some value
indicating the error.
In op_client.c in axis2_op_client_two_way_send() there is code at the very
end, when there is no response envelope, to ensure that an error code is
returned:
if (AXIS2_ERROR_GET_STATUS_CODE(env-error) != AXIS2_SUCCESS)
{
AXIS2_ERROR_SET(env-error,
AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
AXIS2_FAILURE);
if (engine)
{
axis2_engine_free(engine, env);
engine = NULL;
}
axis2_msg_ctx_free(response, env);
return NULL;
}
As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the
intent is to return error number 3 when no other error has been diagnosed.
Unfortunately, even after this fix, in the nightly build of 11/27/07, there
is a new bug that causes error number 3 to be replaced with an uninformative
error 2, invalid null parameter. In svc_client, when the empty response is
returned, axis2_op_client_add_msg_ctx() is called with an intentional null
value clear the ctx.
In the post 1.1 source, parameter validation has been added to
axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_op_client_add_msg_ctx(
axis2_op_client_t * op_client,
const axutil_env_t * env,
axis2_msg_ctx_t * mc)
{
axis2_msg_ctx_t *out_msg_ctx = NULL,
*in_msg_ctx = NULL;
axis2_msg_ctx_t **msg_ctx_map = NULL;
AXIS2_PARAM_CHECK (env-error, op_client, AXIS2_FAILURE);
AXIS2_PARAM_CHECK (env-error, mc, AXIS2_FAILURE);
The second AXIS2_PARAM_CHECK should be removed.
After making both these changes in the development shapshot, when the client
receives no response, for example if the URL points to a non-running server,
the client correctly receives error 3, Blocking invocation expects response.
--
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]
[jira] Commented: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568079#action_12568079 ] Bill Mitchell commented on AXIS2C-963: -- Senaka, it's a good question whether a better fix is available. I considered whether to implement a change down in axiom_stax_builder_create_om_text(), but it doesn't know whether the text is whitespace or not. And I like the fact that non whitespace text before the root element will be diagnosed as an error. To address your concern, one could replicate the test against lastnode in axiom_stax_builder_next_with_token(), before it calls axiom_stax_builder_create_om_text(). Looking at the code again, I actually like that fix better than the one I put in, as it would preserve the ability to detect other errors, and would prevent the error being posted to the environment and then ignored. Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it. - Key: AXIS2C-963 URL: https://issues.apache.org/jira/browse/AXIS2C-963 Project: Axis2-C Issue Type: Bug Components: guththila, xml/parser Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Guththila neglects spacing and formatting between nodes. This behavior contradicts to that of libxml2. Thus, If I open a file then deserialize it and build our OM Model, then print it to the terminal, I have lost the formatting in the file. This is because the parser simply filters out the whitespace. This behavior would make our parsing inconsistent. Regards, Senaka -- 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]
[jira] Resolved: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-963. -- Resolution: Fixed I modified om_stax_builder.c in rev 620703 to tolerate no text node being created when white space text is encountered before the root element. Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it. - Key: AXIS2C-963 URL: https://issues.apache.org/jira/browse/AXIS2C-963 Project: Axis2-C Issue Type: Bug Components: guththila, xml/parser Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Guththila neglects spacing and formatting between nodes. This behavior contradicts to that of libxml2. Thus, If I open a file then deserialize it and build our OM Model, then print it to the terminal, I have lost the formatting in the file. This is because the parser simply filters out the whitespace. This behavior would make our parsing inconsistent. Regards, Senaka -- 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]
[jira] Commented: (AXIS2C-959) Guththila parser can't handle comments.
[ https://issues.apache.org/jira/browse/AXIS2C-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567615#action_12567615 ] Bill Mitchell commented on AXIS2C-959: -- Senaka, I thought your changes looked right, but when I stepped through them on a SOAP message containing a comment, I found the calculated length of the comment was one character too short, so the comment value was getting truncated. It seems the token open/token close logic in guththila expects that the character following the token has already been scanned, here the leading hyphen. I checked in a fix to adjust the next pointer back by 2 instead of 3, in rev 620476. Regards, Bill Guththila parser can't handle comments. --- Key: AXIS2C-959 URL: https://issues.apache.org/jira/browse/AXIS2C-959 Project: Axis2-C Issue Type: Bug Components: guththila Environment: Windows XP SP2, libcurl Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Attachments: diff.txt It seems that Guththila can't properly print comments appreaing in XML. It simply adds an additional '--' at the end unlike it's counterpart libxml2. -- 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]
[jira] Reopened: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-963: -- This change has broken incoming SOAP messages that begin with an xml declaration. What is happening is that guththila interprets the CR-LF after the ?xml ... declaration as GUTHTHILA_SPACE (AXIOM_XML_READER_SPACE) to be returned. But axiom_stax_builder_next_with_token diagnoses an error and returns -1 when the space token cannot be attached as text to the last node (there is no last node) by axiom_stax_builder_create_om_text(). The end result is that the client sees an error number 187, SOAP message does not contain a SOAP envelope element. Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it. - Key: AXIS2C-963 URL: https://issues.apache.org/jira/browse/AXIS2C-963 Project: Axis2-C Issue Type: Bug Components: guththila, xml/parser Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Guththila neglects spacing and formatting between nodes. This behavior contradicts to that of libxml2. Thus, If I open a file then deserialize it and build our OM Model, then print it to the terminal, I have lost the formatting in the file. This is because the parser simply filters out the whitespace. This behavior would make our parsing inconsistent. Regards, Senaka -- 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]
[jira] Commented: (AXIS2C-966) Guththila has no support for XML declarations
[ https://issues.apache.org/jira/browse/AXIS2C-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567627#action_12567627 ] Bill Mitchell commented on AXIS2C-966: -- Senaka, here's another question, while we are both thinking about this. I noticed in axis2_libcurl that it causes the xml declaration to be built, then it determines the text encoding to be inserted in the http content-type header. And I was wondering why this would not be done in the other order? As the http content-type character encoding may be configurable, it would make sense, absent other information, to identify the same character encoding in the http content-type header and in the xml declaration. Guththila has no support for XML declarations - Key: AXIS2C-966 URL: https://issues.apache.org/jira/browse/AXIS2C-966 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.3.0 Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Guththila has no support for XML declarations. Bill, pointed this out in an e-mail sent to the AXIS2C-dev list. It is required that Guththila understands the XML declaration elements and simply do not treat it as an error. Regards, Senaka -- 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]
[jira] Commented: (AXIS2C-966) Guththila has no support for XML declarations
[ https://issues.apache.org/jira/browse/AXIS2C-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567620#action_12567620 ] Bill Mitchell commented on AXIS2C-966: -- Actually, Senaka, I think that guththila could handle other single byte encodings today. Obviously multibyte encodings like UTF-16 are another story. But on the single byte latin encodings, 8859-x, I think all the special characters that are significant to XML are at the same code points. When I was looking at verifying this on incoming messages, the stumbling block I found was that the character encoding from the ?xml declaration is passed up only one layer and then lost, the client app doesn't seem to have a way to learn which encoding was used. Except for that, I think guththila and the rest of Axis2c is neutral for all single byte encodings. Regards, Bill Guththila has no support for XML declarations - Key: AXIS2C-966 URL: https://issues.apache.org/jira/browse/AXIS2C-966 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.3.0 Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Guththila has no support for XML declarations. Bill, pointed this out in an e-mail sent to the AXIS2C-dev list. It is required that Guththila understands the XML declaration elements and simply do not treat it as an error. Regards, Senaka -- 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]
[jira] Commented: (AXIS2C-966) Guththila has no support for XML declarations
[ https://issues.apache.org/jira/browse/AXIS2C-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567513#action_12567513 ] Bill Mitchell commented on AXIS2C-966: -- Senaka, you fixed all the issues I observed at the upper layers. And I have verified that the request message sent via libcurl now contains a ?xml declaration. But the fix works in part by accident. guththila_xml_writer_wrapper_write_start_document_with_version_encoding() now receives a valid encoding and version, so it does not fail the parm checks. But it calls guththila_write_start_document() which accepts no parameters and always generates a ?xml declaration specifying version 1.0 and UTF-8, hardcoded in the string GUTHTHILA_WRITER_SD_DECLARATION. guththila_write_start_document() has no access to the values passed into guththila_xml_writer_wrapper. So if anyone configured the document to specify a different char set encoding, the ?xml declaration would indicate UTF-8 instead of the specified encoding. I'm not sure if this should be tracked as a separate issue, or as part of the same issue. My first inclination would be to reopen it, except that what is there is sufficient, I think, to match the claimed capabilities of 1.3. I don't know that there is yet any functionality in the upper levels to let the client or server app get to the om_output structure and set the char-set encoding. Guththila has no support for XML declarations - Key: AXIS2C-966 URL: https://issues.apache.org/jira/browse/AXIS2C-966 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: 1.3.0 Reporter: Senaka Fernando Assignee: Senaka Fernando Fix For: 1.3.0 Guththila has no support for XML declarations. Bill, pointed this out in an e-mail sent to the AXIS2C-dev list. It is required that Guththila understands the XML declaration elements and simply do not treat it as an error. Regards, Senaka -- 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]
[jira] Updated: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
[
https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-936:
-
Attachment: TemplateSource.diff
Looking at the TemplateSource.xsl file, I think my suggested placement for this
new code is not quite the right place. It think it's adequate to do this only
when deserializing the entire adb_object, so it is easier to place in the xsl
where the adb object deserializing is invoked.
See the attached TemplateSource.diff for a better suggested fix. If the test
for node complete is done immediately after storing the element pointer from
deserialization, it can fit into the normal error flow of testing the status,
freeing the qname, and returning the failure, without risking a memory leak
from building the node and not storing it.
As before, I've generated this fix by inspection of the .xsl file, but I've not
yet created the Java build environment to test the modified .xsl. I have
tested hand modified versions of the generated stubs to verify that they
diagnose the error when the message is incomplete.
On incomplete response message, the client receives response data for the
elements up to the error, but no indication of the error
--
Key: AXIS2C-936
URL: https://issues.apache.org/jira/browse/AXIS2C-936
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml or guththila,
libcurl
Reporter: Bill Mitchell
Fix For: 1.3.0
Attachments: TemplateSource.diff
If the SOAP response message to the client is incomplete, i.e., there is an
EOF indication in the middle of the message, the client receives an object
containing the elements that could be deserialized from the message, with no
indication that the message is incomplete. Clearly, the impact is that the
client may act on the partial message, with no indication anywhere that data
was lost.
I considered whether this could be fixed in svc_client.c. Although it
appears with the debugger that the message is usually complete when at the
end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an
accident of the fact that the lower level code looks for a soap fault in the
soap body, and a SOAP 1.1 response does not have a fault in the body so the
entire body is scanned first looking for the fault. I believe the intent is
that the response be returned without scanning all of the tokens in the body.
So it must be the responsibility of the generated stubs to check that all
the data is processed when deserializing the elements.
At the end of the deserialize method for the response message, there is code
like the following:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed in setting the value
for getExemplarResponse );
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
{
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
/* this is not a nillable element*/
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, non nillable or minOuccrs != 0
element getExemplarResponse missing);
return AXIS2_FAILURE;
}
My suggestion is that an additional test for node complete be added similar
to this:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed in setting the value
for getExemplarResponse );
...
}
if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed to scan entire
element getExemplarResponse );
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
...
It would probably be reasonable and safe to do this as part of all the
generated deserialize routines. But in testing it appears sufficient to do
this in the outermost response element routine, as this assures an error is
returned to the client if the response message is incomplete.
--
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]
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[
https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567024#action_12567024
]
Bill Mitchell commented on AXIS2C-884:
--
You're very welcome.
By the way, to implement a call to initialize libxml in my main thread, I did
not have to include all the libxml includes which caused some conflicts with
other xml related includes I had. Instead I excerpted just the fragment of the
header file for initialization and encapsulated it under an ifdef in my app:
// If libxml2 is used, instead of guththila, then we need to explicitly
initialize outside of Axis2c
#if AXIS_LIBXML_INIT_IN_MAIN_THREAD
// Define libxml entry points directly, to avoid conflicts with Xerces
#ifdef __cplusplus
extern C {
#endif
#include libxml/xmlexports.h
XMLPUBFUN void XMLCALL
xmlInitParser(void);
XMLPUBFUN void XMLCALL
xmlCleanupParser(void);
#ifdef __cplusplus
}
#endif
#endif
Then I added a call to xmlInitParser() in my main thread, again under ifdef,
and worked around the problem. I may have had another issue to make sure that
libxml2 and its friends are built with the VS debug C runtime included in the
manifest, but I had already solved that issue in order to debug libxml2.
The other, simpler workaround is to rebuild Axis to use the guththila parser.
I only went back to libxml2 as I was encountering guththila problems that I
thought would take some time to resolve. All the ones I encountered in my app
have been fixed in 1.3 and it works fine for me. There are a couple of other
minor ones that are preventing the guththila parser becoming the default parser
today. I think the general direction is to move to guththila as soon as
practicable. For your app, like mine, it may be there already.
Seg fault in libxml when svc client torn down in a multithreaded client
---
Key: AXIS2C-884
URL: https://issues.apache.org/jira/browse/AXIS2C-884
Project: Axis2-C
Issue Type: Bug
Components: core/deployment
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml
2.6.30, libcurl
Reporter: Bill Mitchell
Attachments: axis2.trace, desc_builder_diff.txt
In a multithreaded application, if the stub/svc client is freed in a thread
different from that used when the svc client was built, libxml crashes. The
trace below shows the information available from a release build with debug
information embedded.
I have verified this is not an effect of combining debug and release C
runtimes, or different versions of the C runtime. Rebuilding all the libxml
related dlls with the same runtime as is used for Axis and the client app
does not solve the problem.
Interestingly, rebuilding libxml with threads disabled does make the crash go
away. But the default build of libxml commonly available has native threads
enabled, and building without thread support may make the library not thread
safe.
By adding debug trace statements in the axis2.trace file, I have verified
that the xml_reader being torn down when the crash happens is the one used to
read the axis2.xml file when the configuration was first read. (axis2.trace
file attached.)
Looking at the code in libxml, it appears that libxml decides to close the
reader using an internal close routine intended for closing compressed
channels through zlib. Apparently the C runtime library returns a -1 EOF
status when closing a file opened for read. The close routine, gzio.c in
zlib, treats this as an error, and when libxml attempts to report the error
and determines that it is in a different thread, things really go downhill
fast. I have not isolated why the EnterCriticalSection call crashes in the
system, but it does.
One way to avoid the problem would be to guarantee that the stub/svc client
is freed in the same thread as created it. In my multithreaded client
application, though, I work hard to share the stub across threads
deliberately to reduce the number of distinct service clients and the
associated demand on the server.
Windows call traceback at time of crash:
ntdll.dll!7c918fea()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
msvcr80.dll!78134d09()
ntdll.dll!7c910e91()
ntdll.dll!7c9106eb()
msvcr80.dll!78134d83()
ntdll.dll!7c90104b()
libxml2.dll!xmlGetGlobalState() Line 570 C
libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C
libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)*
schannel=0x, void (void *, const char *, no type)*
channel=0x, void * data=0x, void *
[jira] Commented: (AXIS2C-573) Fix warnings on windows
[ https://issues.apache.org/jira/browse/AXIS2C-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567252#action_12567252 ] Bill Mitchell commented on AXIS2C-573: -- I glad to see you are picking these up, Senaka. After changing the Windows makefile to /W3 to enable warnings, I was beginning to get irritated by these, too. Obviously a lot are just AXIS2_PARAM_CHECK calls that return the wrong type, e.g., AXIS2_FAILURE, in a method that is supposed to return a pointer. When I saw the signed/unsigned warnings, though, these set off bells and whistles for me. I've not looked at these in particular, but in other projects on which I have worked, the signed/unsigned warnings are usually real coding errors as the C promotion rules for signed/unsigned do not yield the comparison that a human reader expects. Thanks. Fix warnings on windows Key: AXIS2C-573 URL: https://issues.apache.org/jira/browse/AXIS2C-573 Project: Axis2-C Issue Type: Bug Components: build system (Windows) Environment: Windows Reporter: Nandika Jayawardana Assignee: Senaka Fernando Fix For: 1.3.0 When building axis2c source on windows, there are large number of warnings. These warnings should be fixed -- 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]
[jira] Updated: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[ https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-791: - Attachment: diff.txt Senaka, I worried some about the changes to axis2_op_client_add_msg_ctx. But when I saw that the code already treaterlater on the case of the incoming message_ctx value being zero, I inferred that the author intending zero to be a normal case. It does not surprise me that allowing it to go through this path again uncovered the absence of a guard on the op_ctx pointer in the client being zero, and that this would show up on some path not exercised in the SOAP flow I tested. When I looked at your changes in axis2_op_client_two_way_send, I worried that they defeated the entire purpose of my initial issue. Artificially generating a 75 error might camoflage the error reported at the lower layer. Albeit in my testing the lower layer reported an error 74, almost the same error. But in fact your change here had no effect on the test, as the env error status_code value is false at this point, and gets clobbered to be true at the AXIS2_PARM_CHECK call at the beginning of axis2_op_client_add_msg_ctx. So your change here does no harm, and may remedy some problem, but it does not remedy the problem behavior you saw. I observed this same behavior myself, that lower level routines would post an error number, but that the status code would frequently be changed back to success on the way out. So I inferred that the convention was the caller should not trust the status code, but rather if a null pointer is returned for the response message, the caller should recognize the presence of an error and grab the error number. You suggest that the env status code should always indicate whether an interesting error number is present. That's a perfectly good convention as well, it is clear and understandable, but it means that all the routines on the exit paths from the lower levels back out must not modify the status code when an error is already present, else they will mask the real error -- exactly the problematic behavior I reported. Unfortunately, the standard macros AXIS2_PARAM_CHECK and AXIS2_FUNC_PARAM_CHECK do just that. They report an error if the parameter is null, but they also change the status to success when no error is detected. As a brute force solution to the problematic behavior I reported, I have gone through all the offending routines on the error path from two-way send and changed these to avoid the AXIS2_PARAM_CHECK, to do their own testing inline, and fail appropriately without modifying the env status code when the incoming parameter is valid. (See the attached diff for the affected routines.) At best, this is a fragile solution, as it will be easy for someone to inadvertently introduce new instances of AXIS2_PARAM_CHECK in these or other routines that happen to be used on the error exit path. My suggestion, for discussion, is that AXIS2_PARAM_CHECK and AXIS2_FUNC_PARAM_CHECK routines should never set the env status code to success. Rather, the env status code should be set to success only at the initial outer entry points to the main component routines, and wherever a reported error is ignored and processing continues. But implementing this suggestion requires someone spend a fair amount of time introducing the clearing of the status code in the right places, and the odds are the results will not be perfect on the first pass. Needless to say, I did verify that in my test case, where the server never responds to the connect request, the error number is returned and the status code of failure is now returned all the way out through the generated adb stubs to the application. The attached diff was incorporated in svn rev 619201. On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3. -- Key: AXIS2C-791 URL: https://issues.apache.org/jira/browse/AXIS2C-791 Project: Axis2-C Issue Type: Bug Components: core/clientapi Affects Versions: 1.1.0 Environment: Windows XP, Visual Studio 2005 Reporter: Bill Mitchell Assignee: Bill Mitchell Priority: Minor Fix For: 1.3.0 Attachments: diff.txt If a blocking I/O is requested for an in-out message exchange and no response is received, axis2_svc_client_send_receive et.al. return a zero response pointer. But one would expect the errno variable to contain some value indicating the error. In op_client.c in axis2_op_client_two_way_send() there is code at the very end, when there is no response envelope, to ensure that an error
[jira] Commented: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565776#action_12565776
]
Bill Mitchell commented on AXIS2C-791:
--
Okay, Senaka, you may indeed have run across the same problems I did. I intend
to pick this issue up again today, now that I've checked-in fixes to the
guththila issues I reported.
On in-out message flow that fails with no response, no error code or
misleading error code is returned, expected error number 3.
--
Key: AXIS2C-791
URL: https://issues.apache.org/jira/browse/AXIS2C-791
Project: Axis2-C
Issue Type: Bug
Components: core/clientapi
Affects Versions: 1.1.0
Environment: Windows XP, Visual Studio 2005
Reporter: Bill Mitchell
Assignee: Bill Mitchell
Priority: Minor
If a blocking I/O is requested for an in-out message exchange and no response
is received, axis2_svc_client_send_receive et.al. return a zero response
pointer. But one would expect the errno variable to contain some value
indicating the error.
In op_client.c in axis2_op_client_two_way_send() there is code at the very
end, when there is no response envelope, to ensure that an error code is
returned:
if (AXIS2_ERROR_GET_STATUS_CODE(env-error) != AXIS2_SUCCESS)
{
AXIS2_ERROR_SET(env-error,
AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
AXIS2_FAILURE);
if (engine)
{
axis2_engine_free(engine, env);
engine = NULL;
}
axis2_msg_ctx_free(response, env);
return NULL;
}
As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the
intent is to return error number 3 when no other error has been diagnosed.
Unfortunately, even after this fix, in the nightly build of 11/27/07, there
is a new bug that causes error number 3 to be replaced with an uninformative
error 2, invalid null parameter. In svc_client, when the empty response is
returned, axis2_op_client_add_msg_ctx() is called with an intentional null
value clear the ctx.
In the post 1.1 source, parameter validation has been added to
axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_op_client_add_msg_ctx(
axis2_op_client_t * op_client,
const axutil_env_t * env,
axis2_msg_ctx_t * mc)
{
axis2_msg_ctx_t *out_msg_ctx = NULL,
*in_msg_ctx = NULL;
axis2_msg_ctx_t **msg_ctx_map = NULL;
AXIS2_PARAM_CHECK (env-error, op_client, AXIS2_FAILURE);
AXIS2_PARAM_CHECK (env-error, mc, AXIS2_FAILURE);
The second AXIS2_PARAM_CHECK should be removed.
After making both these changes in the development shapshot, when the client
receives no response, for example if the URL points to a non-running server,
the client correctly receives error 3, Blocking invocation expects response.
--
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]
[jira] Resolved: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell resolved AXIS2C-791.
--
Resolution: Fixed
Fix Version/s: 1.3.0
Fix incorporated in svn rev 618845. To get the send error status returned by
http_transport_sender_write_message out to the client, changes were needed not
only in axis2_engine_send, but in axis2_op_client_add_msg_ctx not to destroy
the error status when a NULL incoming parameter was seen.
On in-out message flow that fails with no response, no error code or
misleading error code is returned, expected error number 3.
--
Key: AXIS2C-791
URL: https://issues.apache.org/jira/browse/AXIS2C-791
Project: Axis2-C
Issue Type: Bug
Components: core/clientapi
Affects Versions: 1.1.0
Environment: Windows XP, Visual Studio 2005
Reporter: Bill Mitchell
Assignee: Bill Mitchell
Priority: Minor
Fix For: 1.3.0
If a blocking I/O is requested for an in-out message exchange and no response
is received, axis2_svc_client_send_receive et.al. return a zero response
pointer. But one would expect the errno variable to contain some value
indicating the error.
In op_client.c in axis2_op_client_two_way_send() there is code at the very
end, when there is no response envelope, to ensure that an error code is
returned:
if (AXIS2_ERROR_GET_STATUS_CODE(env-error) != AXIS2_SUCCESS)
{
AXIS2_ERROR_SET(env-error,
AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
AXIS2_FAILURE);
if (engine)
{
axis2_engine_free(engine, env);
engine = NULL;
}
axis2_msg_ctx_free(response, env);
return NULL;
}
As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the
intent is to return error number 3 when no other error has been diagnosed.
Unfortunately, even after this fix, in the nightly build of 11/27/07, there
is a new bug that causes error number 3 to be replaced with an uninformative
error 2, invalid null parameter. In svc_client, when the empty response is
returned, axis2_op_client_add_msg_ctx() is called with an intentional null
value clear the ctx.
In the post 1.1 source, parameter validation has been added to
axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_op_client_add_msg_ctx(
axis2_op_client_t * op_client,
const axutil_env_t * env,
axis2_msg_ctx_t * mc)
{
axis2_msg_ctx_t *out_msg_ctx = NULL,
*in_msg_ctx = NULL;
axis2_msg_ctx_t **msg_ctx_map = NULL;
AXIS2_PARAM_CHECK (env-error, op_client, AXIS2_FAILURE);
AXIS2_PARAM_CHECK (env-error, mc, AXIS2_FAILURE);
The second AXIS2_PARAM_CHECK should be removed.
After making both these changes in the development shapshot, when the client
receives no response, for example if the URL points to a non-running server,
the client correctly receives error 3, Blocking invocation expects response.
--
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]
[jira] Created: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue
libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue --- Key: AXIS2C-967 URL: https://issues.apache.org/jira/browse/AXIS2C-967 Project: Axis2-C Issue Type: Bug Components: transport/http Environment: Windows XP, Visutal Studio 2005, libxml, libcurl Reporter: Bill Mitchell After receiving an HTTP response, the axis2_libcurl code assumes the first response line is the HTTP status line, and grabs the status code therein. While watching this communicate to an IIS server, I noticed that the first response was an HTTP 1.1/100 Continue, and the real status line was several lines later. I don't know if IIS sends the 100 Continue all of the time or just some of the time; regardless, it is allowed in the HTTP RFC 2616. The libcurl code needs to read through to find the first non-1xx HTTP status line, or process these headers in reverse order and grab the code from the last status line received. -- 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]
[jira] Commented: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565466#action_12565466 ] Bill Mitchell commented on AXIS2C-933: -- Fix included in svn rev 618364. guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault --- Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell Assignee: Bill Mitchell Fix For: 1.3.0 Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Resolved: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-859. -- Resolution: Fixed Assignee: Bill Mitchell I checked in Lahiru and my fixes to guththila_xml_parser and guththila_xml_writer in svn rev 618378. guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Assignee: Bill Mitchell Fix For: 1.3.0 Attachments: diff.txt, diff_1.txt, diff_2.txt, guththila_xml_writer.diff When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Resolved: (AXIS2C-812) guththila parser fails attempting to deallocate unallocated cell if xml message contains more than one namespace
[ https://issues.apache.org/jira/browse/AXIS2C-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-812. -- Resolution: Fixed Fix Version/s: 1.3.0 guththila parser fails attempting to deallocate unallocated cell if xml message contains more than one namespace Key: AXIS2C-812 URL: https://issues.apache.org/jira/browse/AXIS2C-812 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows, Visual Studio 2005, guththila validating parser Reporter: Bill Mitchell Fix For: 1.3.0 Attachments: guththila_xml_parser_diff, guththila_xml_parser_diff_2 The guththila validating parser fails attempting to deallocate an unallocated cell if the xml message constains more than one namespace. The issue is that the validating parser allocates one cell of memory to hold an array of namespaces, but that the code that frees the namespaces believes that each array element is a separate cell. Thus, if the array contains more than one element, the free of the second element fails. One can see the problem when parsing a SOAP response message identifying two namespaces, e.g., one that begins: ?xml version=1.0 encoding=UTF-8 ? - env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; - env:Body ... This appears to be a problem introduced as part of fix AXIS2C-785 since 1.1.0 in the development branch; in 1.1.0 the array was not freed at all. -- 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]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: guththila_xml_parser.diff For reference, in the attached guththila_xml_parser.diff is the patch to just the problems described in this issue. I will apply it shortly. guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault --- Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell Fix For: 1.3.0 Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: (was: diff2.txt) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault --- Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell Attachments: diff.txt The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Resolved: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-933. -- Resolution: Fixed Assignee: Bill Mitchell guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault --- Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell Assignee: Bill Mitchell Fix For: 1.3.0 Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Resolved: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
[
https://issues.apache.org/jira/browse/AXIS2C-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell resolved AXIS2C-944.
--
Resolution: Fixed
Assignee: Bill Mitchell
This fix has been applied as svn rev 618521.
guththila parser ignores XML scope rules on namespace declarations with the
same prefix
---
Key: AXIS2C-944
URL: https://issues.apache.org/jira/browse/AXIS2C-944
Project: Axis2-C
Issue Type: Bug
Components: guththila
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
Assignee: Bill Mitchell
Fix For: 1.3.0
Attachments: diff.txt
The guththila parser looks for a match on the namespace prefix/URI from the
outermost element inwards. This violates the scope rules for XML namespaces,
see http://www.w3.org/TR/REC-xml-names/. This problem holds for both
incoming messages in guththila_xml_parser.c and outgoing messages in
guththila_xml_writer.c. Essentially every loop involving
guththila_stack_get_by_index() is suspect, and either needs to start at
(stack_size - 1) and go backwards, or fetch the namespace at the (stack_size
- 1 - i) index.
I uncovered this by inspection, not by testing, so there is some chance that
my understanding is incorrect. But I looked at guththila_stack.c and indeed
for index 0 it returns the outermost/first element pushed, so there is no
tricky logic there to get the stack in the other order. Of course, one could
indeed fix this problem by changing guththila_stack_get_by_index() to return
the elements from the innermost/most recently pushed back out to the
outermost. This would be the easiest fix to make, and the safest in that it
would not change the logic in any of the existing loops, although it would
seem less clear to the casual reader.
In other words, the current logic:
guththila_stack_get_by_index(
guththila_stack_t * stack,
int index,
const axutil_env_t * env)
{
return index stack-top ? stack-data[index] : NULL;
}
could be changed to read:
{
return index stack-top ? stack-data[stack-top - index - 1] : NULL;
}
--
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]
[jira] Updated: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
[
https://issues.apache.org/jira/browse/AXIS2C-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-944:
-
Attachment: diff.txt
The attached diff contains changes to conform to the XML namespace scope rules
by searching the namespace stack from the inside out.
As well, having enabled warning messages in the Windows NMAKE makefile, I have
fixed several mismatched signed/unsigned conflicts that the compiler diagnosed.
And the relatively new guththila_token_close routines were moved intact after
the expected first entry points of create/init/free.
guththila parser ignores XML scope rules on namespace declarations with the
same prefix
---
Key: AXIS2C-944
URL: https://issues.apache.org/jira/browse/AXIS2C-944
Project: Axis2-C
Issue Type: Bug
Components: guththila
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
Fix For: 1.3.0
Attachments: diff.txt
The guththila parser looks for a match on the namespace prefix/URI from the
outermost element inwards. This violates the scope rules for XML namespaces,
see http://www.w3.org/TR/REC-xml-names/. This problem holds for both
incoming messages in guththila_xml_parser.c and outgoing messages in
guththila_xml_writer.c. Essentially every loop involving
guththila_stack_get_by_index() is suspect, and either needs to start at
(stack_size - 1) and go backwards, or fetch the namespace at the (stack_size
- 1 - i) index.
I uncovered this by inspection, not by testing, so there is some chance that
my understanding is incorrect. But I looked at guththila_stack.c and indeed
for index 0 it returns the outermost/first element pushed, so there is no
tricky logic there to get the stack in the other order. Of course, one could
indeed fix this problem by changing guththila_stack_get_by_index() to return
the elements from the innermost/most recently pushed back out to the
outermost. This would be the easiest fix to make, and the safest in that it
would not change the logic in any of the existing loops, although it would
seem less clear to the casual reader.
In other words, the current logic:
guththila_stack_get_by_index(
guththila_stack_t * stack,
int index,
const axutil_env_t * env)
{
return index stack-top ? stack-data[index] : NULL;
}
could be changed to read:
{
return index stack-top ? stack-data[stack-top - index - 1] : NULL;
}
--
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]
[jira] Updated: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-859: - Attachment: guththila_xml_writer.diff diff_2.txt Lahiru, looking at the code again, I now agree that you were right to replace the character by sliding the token data down. I was under the mistaken impression that the code was sliding all the rest of the buffer down; as long as we are sliding from one end or the other of the token, there is no reason not do the obvious slide down. In the attached diff_2.txt, I moved the code to perform the replacement into a lower level routine. As guththila_close_token has constructed a temp token in both the text case and the attribute value case, it is easy to perform replacement on this temp token string before further processing of the attribute for a namespace declaration. Beware that the line number where we change the token type to _text may be different in yours; my version includes changes for AXIS2C-933 that Supun wants to review before they are applied. Separately, in the attached guththila_xml_writer.diff, is a patch to other side of this issue, the insertion of character sequences on outgoing messages that include ampersand or greater than in the text. With both fixes installed, I was able to see ampersand data characters from the client arrive at the server intact, and vice versa. guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Attachments: diff.txt, diff_1.txt, diff_2.txt, guththila_xml_writer.diff When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Updated: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-859: - Attachment: (was: diff_2.txt) guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Attachments: diff.txt, diff_1.txt, diff_2.txt, guththila_xml_writer.diff When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Updated: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-859: - Attachment: diff_2.txt guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Attachments: diff.txt, diff_1.txt, diff_2.txt, guththila_xml_writer.diff When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Resolved: (AXIS2C-818) If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer
[ https://issues.apache.org/jira/browse/AXIS2C-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-818. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix has been applied as svn revision 617570. If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer -- Key: AXIS2C-818 URL: https://issues.apache.org/jira/browse/AXIS2C-818 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.1.0 Environment: Windows, Visual Studio 2005, debug build, libcurl enabled, guththila parser enabled Reporter: Bill Mitchell Fix For: Current (Nightly) Attachments: http_transport_utils_diff If the returned message from libcurl exceeds 4096 characters, the size of a guththila buffer, http_transport_utils clobbers the byte following the end of the buffer. When running the Windows version in debug mode, this is nicely diagnosed by the C runtime as a heap corruption failure. The problem lies in axis2_http_transport_utils_on_data_request() where it always stores a zero byte past the end of the data read, even if the data read fully fills the size of the provided buffer. As I don't know the intent of storing the zero byte, It's not clear to me which of 3 remedies is best: (1) don't ever store the zero byte, it's past the end of the bytes read (2) store the zero byte only if fewer characters were read than the size of the buffer (3) always read one byte less than the size of the buffer, thus guaranteeing space for a terminating null byte -- 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]
[jira] Resolved: (AXIS2C-834) guththila_xml_writer has problems with default namespace
[ https://issues.apache.org/jira/browse/AXIS2C-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-834. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix has been incorporated in svn rev 617651. 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 Fix For: Current (Nightly) 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]
[jira] Resolved: (AXIS2C-830) libcurl interface not multithreaded
[ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-830. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix to this problem has been incorporated in svn revision 617668. libcurl interface not multithreaded --- Key: AXIS2C-830 URL: https://issues.apache.org/jira/browse/AXIS2C-830 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 1.1.0 Environment: Windows XP, Visual Studio 2005, build uses libcurl and guththila Reporter: Bill Mitchell Fix For: Current (Nightly) Attachments: libcurl_diff Axis2C support of libcurl is not multithreaded, i.e., it cannot be invoked by a multithreaded client application. This despite the fact that libcurl is multithreaded and Axis2C is multithreaded. The crux of the issue lies in the static global definition of the curl handler in axis2_libcurl.c. This prevents multiple client threads from obtaining multiple connections to issue concurrent SOAP operations. -- 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]
[jira] Commented: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564962#action_12564962 ] Bill Mitchell commented on AXIS2C-857: -- I noticed that along the way a change in Lahiru's patch to fix guththila_tok_tok_cmp to scan all the characters in the token was not applied in the final patch. This fix is now restored in svn rev 617685. guththila parser drops xml:id attributes from incoming elements --- Key: AXIS2C-857 URL: https://issues.apache.org/jira/browse/AXIS2C-857 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Assignee: Dinesh Premalal Priority: Minor Fix For: 1.2.1 Attachments: diff.txt, diff2.txt, diff_mod.txt The XML specification allows an element to carry an xml:id attribute without the xml namespace being declared explicitly. In fact, if the xml namespace is declared, it must match http://www.w3.org/XML/1998/namespace. When the namespace is not declared explicitly, it appears that the guththila parser discards the incoming xml:id attributes without including them in the om. For example, I receive a response message from a service that begins: env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:fw=http://frameware.xcentrisity.com/services/; env:Body fw:getExemplarResponse responseMessage=master exemplar provided. name=customer supportedMethods=browse browseNext browsePrevious create update delete retrieve exemplar handle=master cr-customer-record xml:id=Q375 type=xsd:string cr-customer-id xml:id=Q376 type=xsd:string /cr-customer-id ... When linked with libxml, the client code sees two attributes, a type attribute and an xml:id attribute, attached to the element nodes. When linked with the guththila parser, only the type attribute is present. -- 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]
[jira] Commented: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
[
https://issues.apache.org/jira/browse/AXIS2C-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1256#action_1256
]
Bill Mitchell commented on AXIS2C-944:
--
Looking at the code in more detail, I see that guththila_xml_writer examines
the namespace 7 times from the outermost to the innermost, and twice the
correct way from the innermost to the outermost. All two times that
guththila_xml_parser.c examines the namespace stack, it does it from the
outermost to the innermost, i.e., in the wrong order.
guththila_get_namespace_prefix_by_number(),
guththila_get_namespace_uri_by_number() makes the use of the number visible to
the caller. These are used by the guththila_main sample program, and
interestingly use 1-origin indexing.
guththila_get_attribute_XXX_by_number() uses the same stack routines, so the
stack construct is not used just for namespaces. As with the
guththila_get_namespace_XXX_by_number() routines, these are used by the
guththila_main sample program and use 1-origin indexing.
Given the additional interface routines that make the numbering scheme visible
publicly, the right solution appears to be to fix the offending loops in
guththila_xml_parser.c and guththila_xml_writer.c to examine the stack from the
higher index down to zero. Not the clever solution to number the stack from
the top of the stack backwards.
guththila parser ignores XML scope rules on namespace declarations with the
same prefix
---
Key: AXIS2C-944
URL: https://issues.apache.org/jira/browse/AXIS2C-944
Project: Axis2-C
Issue Type: Bug
Components: guththila
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
The guththila parser looks for a match on the namespace prefix/URI from the
outermost element inwards. This violates the scope rules for XML namespaces,
see http://www.w3.org/TR/REC-xml-names/. This problem holds for both
incoming messages in guththila_xml_parser.c and outgoing messages in
guththila_xml_writer.c. Essentially every loop involving
guththila_stack_get_by_index() is suspect, and either needs to start at
(stack_size - 1) and go backwards, or fetch the namespace at the (stack_size
- 1 - i) index.
I uncovered this by inspection, not by testing, so there is some chance that
my understanding is incorrect. But I looked at guththila_stack.c and indeed
for index 0 it returns the outermost/first element pushed, so there is no
tricky logic there to get the stack in the other order. Of course, one could
indeed fix this problem by changing guththila_stack_get_by_index() to return
the elements from the innermost/most recently pushed back out to the
outermost. This would be the easiest fix to make, and the safest in that it
would not change the logic in any of the existing loops, although it would
seem less clear to the casual reader.
In other words, the current logic:
guththila_stack_get_by_index(
guththila_stack_t * stack,
int index,
const axutil_env_t * env)
{
return index stack-top ? stack-data[index] : NULL;
}
could be changed to read:
{
return index stack-top ? stack-data[stack-top - index - 1] : NULL;
}
--
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]
[jira] Commented: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564199#action_12564199 ] Bill Mitchell commented on AXIS2C-859: -- Lahira, after yesterday I researched again the XML spec and I find that it says that replacement of XML characters and entity references happens on the URI to generate the normalized value. So it seems we have to do this character replacement logic on the attribute value string before we process it as a possible namespace declaration. Just another extra wrinkle. My second item above alluded to a different solution, built into guththila_next() instead of guththila_token_close(). One could imagine, in the right loops in guththila_next where we are looking at the characters one at a time anyway, we could detect the leading ampersand, check the next 4 or 5 characters against the XML character reference values, and replace the character there, again as above sliding the leading part of the token to abut the smaller single character. This would avoid a second pass over the token characters looking for the ampersands, but I suspect it would make guththila_next() much harder to understand than it already is. So my second point above was just to say that I think you have chosen the better approach, to handle this issue of XML character entities in guthtila_token_close() well separate from the token parsing in guththila_next(). guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Attachments: diff.txt When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Reopened: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-857: -- Probably thanks to Lahira and I cooperating to work on the patch, we ended up with a version in diff.txt that introduced the logic to create an xml: namespace declaration twice in guththila_init(). Obviously one of the two identical blocks of following code needs to be removed. Starting with temp_name = guththila_token_create(GUTHTHILA_XML_NAME,0,strlen(GUTHTHILA_XML_NAME), 1,0,0,env); temp_tok = guththila_token_create(GUTHTHILA_XML_URI,0,strlen(GUTHTHILA_XML_URI), 1,0,0,env); through the end of the new code at: e_namesp = NULL; } return GUTHTHILA_FAILURE; } guththila parser drops xml:id attributes from incoming elements --- Key: AXIS2C-857 URL: https://issues.apache.org/jira/browse/AXIS2C-857 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Assignee: Dinesh Premalal Priority: Minor Fix For: 1.2.1 Attachments: diff.txt, diff2.txt The XML specification allows an element to carry an xml:id attribute without the xml namespace being declared explicitly. In fact, if the xml namespace is declared, it must match http://www.w3.org/XML/1998/namespace. When the namespace is not declared explicitly, it appears that the guththila parser discards the incoming xml:id attributes without including them in the om. For example, I receive a response message from a service that begins: env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:fw=http://frameware.xcentrisity.com/services/; env:Body fw:getExemplarResponse responseMessage=master exemplar provided. name=customer supportedMethods=browse browseNext browsePrevious create update delete retrieve exemplar handle=master cr-customer-record xml:id=Q375 type=xsd:string cr-customer-id xml:id=Q376 type=xsd:string /cr-customer-id ... When linked with libxml, the client code sees two attributes, a type attribute and an xml:id attribute, attached to the element nodes. When linked with the guththila parser, only the type attribute is present. -- 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]
[jira] Created: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
guththila parser ignores XML scope rules on namespace declarations with the
same prefix
---
Key: AXIS2C-944
URL: https://issues.apache.org/jira/browse/AXIS2C-944
Project: Axis2-C
Issue Type: Bug
Components: guththila
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
The guththila parser looks for a match on the namespace prefix/URI from the
outermost element inwards. This violates the scope rules for XML namespaces,
see http://www.w3.org/TR/REC-xml-names/. This problem holds for both incoming
messages in guththila_xml_parser.c and outgoing messages in
guththila_xml_writer.c. Essentially every loop involving
guththila_stack_get_by_index() is suspect, and either needs to start at
(stack_size - 1) and go backwards, or fetch the namespace at the (stack_size -
1 - i) index.
I uncovered this by inspection, not by testing, so there is some chance that my
understanding is incorrect. But I looked at guththila_stack.c and indeed for
index 0 it returns the outermost/first element pushed, so there is no tricky
logic there to get the stack in the other order. Of course, one could indeed
fix this problem by changing guththila_stack_get_by_index() to return the
elements from the innermost/most recently pushed back out to the outermost.
This would be the easiest fix to make, and the safest in that it would not
change the logic in any of the existing loops, although it would seem less
clear to the casual reader.
In other words, the current logic:
guththila_stack_get_by_index(
guththila_stack_t * stack,
int index,
const axutil_env_t * env)
{
return index stack-top ? stack-data[index] : NULL;
}
could be changed to read:
{
return index stack-top ? stack-data[stack-top - index - 1] : NULL;
}
--
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]
[jira] Commented: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563745#action_12563745 ] Bill Mitchell commented on AXIS2C-859: -- Thanks for picking up this issue, Lahiru. I was thinking about starting to look at it in detail myself. Examining the patch, I have a couple thoughts. First, you allocate a block of memory, escape_char, to hold the copy of the token to this point. But the size of the block is 4 on most machines, the sizeof a pointer to char. So this size will frequently not be enough to copy all the characters preceding the escaped character. It occurs to me that guththila tries to go to a lot of effort to avoid allocating memory. Having worked on some issues recently in the buffer management code, I would propose a different solution: moving the data in the buffer itself. Although the obvious solution would be to replace the escaped sequence with the intended character and slide the remainder of the buffer down, this could be timeconsuming. A clever idea might be to replace the escaped sequence, placing the intended character at the end of the sequence, and copy the characters up from the start of the token, moving the token start up and reducing its size. In most cases, this would not be a large amount of data to move, and it avoids the memory allocation entirely. Second, I like where you chose to insert this code, in the token_close logic. Although I can imagine trying to make this part of guththila_next, where it could massage the buffer contents while it was deciding where the token boundaries are, it seems best to leave that logic deciding where the edges of the tokens are without changing the characters inside the tokens. Third, looking at the examples of character escaping in various texts, it appears that one can find escaped character sequences in text and in attribute values. So this logic either needs to be duplicated, not pretty, or pushed down into a lower level shared routine. Fourth, you inserted this logic in the _char_data: case. It appears to me from the XML documentation that we are supposed to replace sequences in text, but not in comments. guththila_next() seems to confuse this issue, as it treats them both as _char_data. To distinguish the two, my guess is it would be better to define a new token type, rather than cheat and look at the m-guththila_event to tell them apart. A new token type might point the direction to solving the CDATA problem, whenever that gets approached. Maybe use _char_data for the raw char data, without processing, and a new _text_data for char data that undergoes processing of entity sequences. Fifth, when checking the following characters after the ampersand, it would be best to check first that enough characters are left in the token, before looking at the characters themselves and perhaps falling off the end of the buffer. Of course, I'm relatively new to this logic, so these are just my observations. guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Attachments: diff.txt When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Created: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
On incomplete response message, the client receives response data for the
elements up to the error, but no indication of the error
--
Key: AXIS2C-936
URL: https://issues.apache.org/jira/browse/AXIS2C-936
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml or guththila,
libcurl
Reporter: Bill Mitchell
If the SOAP response message to the client is incomplete, i.e., there is an EOF
indication in the middle of the message, the client receives an object
containing the elements that could be deserialized from the message, with no
indication that the message is incomplete. Clearly, the impact is that the
client may act on the partial message, with no indication anywhere that data
was lost.
I considered whether this could be fixed in svc_client.c. Although it appears
with the debugger that the message is usually complete when at the end of
axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident
of the fact that the lower level code looks for a soap fault in the soap body,
and a SOAP 1.1 response does not have a fault in the body so the entire body is
scanned first looking for the fault. I believe the intent is that the response
be returned without scanning all of the tokens in the body. So it must be the
responsibility of the generated stubs to check that all the data is processed
when deserializing the elements.
At the end of the deserialize method for the response message, there is code
like the following:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed in setting the value
for getExemplarResponse );
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
{
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
/* this is not a nillable element*/
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, non nillable or minOuccrs != 0
element getExemplarResponse missing);
return AXIS2_FAILURE;
}
My suggestion is that an additional test for node complete be added similar to
this:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed in setting the value
for getExemplarResponse );
...
}
if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed to scan entire element
getExemplarResponse );
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
...
It would probably be reasonable and safe to do this as part of all the
generated deserialize routines. But in testing it appears sufficient to do
this in the outermost response element routine, as this assures an error is
returned to the client if the response message is incomplete.
--
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]
[jira] Commented: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
[
https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563044#action_12563044
]
Bill Mitchell commented on AXIS2C-936:
--
Looking at this again in the log, it would be more clear if the error message
read something like:
element getExemplarResponse is not complete.
On incomplete response message, the client receives response data for the
elements up to the error, but no indication of the error
--
Key: AXIS2C-936
URL: https://issues.apache.org/jira/browse/AXIS2C-936
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml or guththila,
libcurl
Reporter: Bill Mitchell
If the SOAP response message to the client is incomplete, i.e., there is an
EOF indication in the middle of the message, the client receives an object
containing the elements that could be deserialized from the message, with no
indication that the message is incomplete. Clearly, the impact is that the
client may act on the partial message, with no indication anywhere that data
was lost.
I considered whether this could be fixed in svc_client.c. Although it
appears with the debugger that the message is usually complete when at the
end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an
accident of the fact that the lower level code looks for a soap fault in the
soap body, and a SOAP 1.1 response does not have a fault in the body so the
entire body is scanned first looking for the fault. I believe the intent is
that the response be returned without scanning all of the tokens in the body.
So it must be the responsibility of the generated stubs to check that all
the data is processed when deserializing the elements.
At the end of the deserialize method for the response message, there is code
like the following:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed in setting the value
for getExemplarResponse );
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
{
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
/* this is not a nillable element*/
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, non nillable or minOuccrs != 0
element getExemplarResponse missing);
return AXIS2_FAILURE;
}
My suggestion is that an additional test for node complete be added similar
to this:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed in setting the value
for getExemplarResponse );
...
}
if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, failed to scan entire
element getExemplarResponse );
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
...
It would probably be reasonable and safe to do this as part of all the
generated deserialize routines. But in testing it appears sufficient to do
this in the outermost response element routine, as this assures an error is
returned to the client if the response message is incomplete.
--
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]
[jira] Updated: (AXIS2C-933) guththila parser fails when incoming message longer than 16984 characters
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: diff2.txt I agree, Supun, that I misunderstood the buffs variable as accumulating the size of all the buffers to date. It is in fact the size of just this buffer. And, although I understood the logic of copying the start of the token from the last buffer to the new buffer, I was imagining only the easy case of a short token, where another buffer of the same size works fine. The doubling in size handles the unusual case when a large amount of element content must be copied from the previous buffer. I suspected, after I wrote up the issue, that it was better seen from the last problem forward. As I was unintentionally testing the path of an incomplete message from the service, the core issue is that there are several while loops in guththila that do not exit on end-of-file. So they continue to call guththila_next_char. This infinite loop leads to a secondary failure, as guththila_next_char will allocate another buffer, double in size, on each attempt to read at end-of-file. Eventually this memory allocation fails, but as guththila does not check for memory allocation failure, the ending symptom is a seg fault in the buffer management logic. Attached is a revised version of the first patch, that leaves the buffer doubling logic intact, but remedies all the other issues I described and addressed in the first patch. Having implemented a fix for this, I discovered that the fact that the message is incomplete gets lost in the upper layers, so the client ends up seeing a partial message as if it is the entire message. But that is a different issue that can be addressed separately. guththila parser fails when incoming message longer than 16984 characters - Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell Attachments: diff.txt, diff2.txt The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Summary: guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault (was: guththila parser fails when incoming message longer than 16984 characters) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault --- Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell Attachments: diff.txt, diff2.txt The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Created: (AXIS2C-933) guththila parser fails when incoming message longer than 16984 characters
guththila parser fails when incoming message longer than 16984 characters - Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- 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]
[jira] Updated: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-857: - Attachment: diff2.txt Lahira, it's a nice start on a patch; it's certainly in the right direction. In testing it I uncovered a few minor coding errors. In guththila_init(), (a) the declarations needed to come at the start of the block, (b) the namespace size is getting setting wrong, as it needs strlen(), sizeof is rounding up to the next multiple of the machine word, (c) the code did not handle out-of-memory on the token creates. In guththila_token_create, (d) it was allocating the wrong length of for the string and the token structure, and (e) it was not actually returning the pointer to the allocated token to the caller. In the attached diff2.txt, I corrected the coding errors and the client app now sees the xml:id attributes on the elements and can process them. Thanks for getting this started. guththila parser drops xml:id attributes from incoming elements --- Key: AXIS2C-857 URL: https://issues.apache.org/jira/browse/AXIS2C-857 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Priority: Minor Attachments: diff.txt, diff2.txt The XML specification allows an element to carry an xml:id attribute without the xml namespace being declared explicitly. In fact, if the xml namespace is declared, it must match http://www.w3.org/XML/1998/namespace. When the namespace is not declared explicitly, it appears that the guththila parser discards the incoming xml:id attributes without including them in the om. For example, I receive a response message from a service that begins: env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:fw=http://frameware.xcentrisity.com/services/; env:Body fw:getExemplarResponse responseMessage=master exemplar provided. name=customer supportedMethods=browse browseNext browsePrevious create update delete retrieve exemplar handle=master cr-customer-record xml:id=Q375 type=xsd:string cr-customer-id xml:id=Q376 type=xsd:string /cr-customer-id ... When linked with libxml, the client code sees two attributes, a type attribute and an xml:id attribute, attached to the element nodes. When linked with the guththila parser, only the type attribute is present. -- 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]
[jira] Created: (AXIS2C-927) axiom_element_declare_default_namespace fails when no namespace already declared
axiom_element_declare_default_namespace fails when no namespace already declared
Key: AXIS2C-927
URL: https://issues.apache.org/jira/browse/AXIS2C-927
Project: Axis2-C
Issue Type: Bug
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
If axiom_element_declare_default_namespace() is called before any named
namespace is declared, it fails to perform the axutil_hash_make and as a result
axutil_hash_set crashes on the empty namespace pointer.
The code fragment:
if (om_element-namespaces)
{
om_element-namespaces = axutil_hash_make(env);
if (!(om_element-namespaces))
{
return NULL;
}
}
should read:
if (!om_element-namespaces)
{
om_element-namespaces = axutil_hash_make(env);
if (!(om_element-namespaces))
{
return NULL;
}
}
--
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]
[jira] Updated: (AXIS2C-927) axiom_element_declare_default_namespace fails when no namespace already declared
[
https://issues.apache.org/jira/browse/AXIS2C-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-927:
-
Attachment: om_element_diff
axiom_element_declare_default_namespace fails when no namespace already
declared
Key: AXIS2C-927
URL: https://issues.apache.org/jira/browse/AXIS2C-927
Project: Axis2-C
Issue Type: Bug
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
Attachments: om_element_diff
If axiom_element_declare_default_namespace() is called before any named
namespace is declared, it fails to perform the axutil_hash_make and as a
result axutil_hash_set crashes on the empty namespace pointer.
The code fragment:
if (om_element-namespaces)
{
om_element-namespaces = axutil_hash_make(env);
if (!(om_element-namespaces))
{
return NULL;
}
}
should read:
if (!om_element-namespaces)
{
om_element-namespaces = axutil_hash_make(env);
if (!(om_element-namespaces))
{
return NULL;
}
}
--
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]
[jira] Commented: (AXIS2C-834) guththila_xml_writer has problems with default namespace
[ https://issues.apache.org/jira/browse/AXIS2C-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 81Asm guththila.dll!guththila_write_namespace(guththila_xml_writer_s * wr=0x027e43d8, char * prefix=0x, 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=0x, 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=0x, 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 bytesC 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 bytesC 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 bytesC axis2_engine.dll!axis2_svc_client_send_receive_with_op_qname(axis2_svc_client * svc_client=0x01755028, const axutil_env * env=0x0172b450, const
[jira] Created: (AXIS2C-925) seg fault in axiom_soap_fault_get_text if SOAP 1.1
seg fault in axiom_soap_fault_get_text if SOAP 1.1 -- Key: AXIS2C-925 URL: https://issues.apache.org/jira/browse/AXIS2C-925 Project: Axis2-C Issue Type: Bug Components: xml/soap Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml2, libcurl Reporter: Bill Mitchell If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the client calls axiom_soap_fault_get_text. At the time of the crash, using the debugger the om_ele_node in the fault_value points to memory that has been reused, probably as a result of being released. When axiom_element_get_text is called, the data_element it is passed appears to be overwritten or reused, so axiom_element_get_text sees om_element-text_value as nonzero, tries to free it, and the C runtime diagnoses a memory management error on the free. Stepping through with the debugger, the crux of the problem lies in soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the fault_value_node, converts its contents to text, issues the free_tree to free the node and its children, but leaves the pointer as the axiom_soap_fault_value_base_node. So the later call to axiom_soap_fault_get_text believes there is still a node tree structure present. The same oversight occurs when processing the fault_reason. The axiom_soap_fault_text_base_node is detached, converted to a single text string, the node tree is freed, but the pointer is left as the axiom_soap_fault_base_node. -- 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]
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558762#action_12558762 ] Bill Mitchell commented on AXIS2C-884: -- One reason it is difficult to isolate exactly what is happening is that WindowsXP exhibits different behavior in a multiple CPU environment than it does in a single CPU environment. In a single CPU environment, using axis2_options_set_xml_parser_reset to disable the xmlCleanupParser() call on each service termination may succeed in avoiding the libxml seg faults. This does not work in the multiple CPU environment, as seen in the crash below. This crash can happen even when only one service is created and there is no parser reset call, provided that the service is created in a transient thread that no longer exists when the service is freed. ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80e98b() msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int nBlockUse=0, const char * szFileName=0x239c, int nLine=40696612) Line 268 + 0x15 bytesC++ msvcr80d.dll!malloc(unsigned int nSize=16809748) Line 154 + 0x15 bytes C++ libxml2.dll!xmlGetGlobalState() Line 570 C libxml2.dll!__xmlDefaultSAXHandler() Line 821 + 0x5 bytes C libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x02ac6b88) Line 1691 + 0xd bytes C libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x02a81898) Line 2196 + 0xc bytesC axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader * parser=0x02ade048, const axutil_env * env=0x019cb498) Line 512 + 0x9 bytes C axis2_parser.dll!axiom_xml_reader_free(axiom_xml_reader * parser=0x02ade048, const axutil_env * env=0x019cb498) Line 35C axiom.dll!axiom_stax_builder_free(axiom_stax_builder * om_builder=0x02b07938, const axutil_env * env=0x019cb498) Line 885 C axiom.dll!axiom_soap_builder_free(axiom_soap_builder * soap_builder=0x02a875e8, const axutil_env * env=0x019cb498) Line 189C axiom.dll!axiom_soap_envelope_free(axiom_soap_envelope * soap_envelope=0x02a85a58, const axutil_env * env=0x019cb498) Line 168 C axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x02aa5e18, const axutil_env * env=0x019cb498) Line 374C axis2_engine.dll!axis2_op_ctx_free(axis2_op_ctx * op_ctx=0x02aea0a0, const axutil_env * env=0x019cb498) Line 165 C axis2_engine.dll!axis2_op_client_free(axis2_op_client * op_client=0x02aa3ca8, const axutil_env * env=0x019cb498) Line 615 C axis2_engine.dll!axis2_svc_client_free(axis2_svc_client * svc_client=0x019f5028, const axutil_env * env=0x019cb498) Line 1287 C axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x019cb760, const axutil_env * env=0x019cb498) Line 129 C I have not delved into the lower level Windows code to see if the thread management is doing something special in the multiple CPU case, or if this is just a race condition that appears more easily in a multi-CPU environment. Evidently, the only way to avoid the crash is to create Axis initialization and termination entry points, as suggested above, that can be called by the application in a persistent thread, or to build enough functionality into guththila that it can replace libxml. As it stands today, for the multithreaded application to avoid the crash it must perform the xmlInitParser() call to libxml2 itself when it starts up, before multithreaded processing begins, and also set_xml_parser_reset false in the options of every service client. Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell Attachments: axis2.trace, desc_builder_diff.txt In a multithreaded application, if the stub/svc client is freed in a thread different from that used when the svc client was built, libxml crashes. The trace below shows the information available from a release build with debug information embedded. I have verified this is not an effect of combining debug and release C runtimes, or different versions of the C runtime. Rebuilding all the libxml related dlls with the same runtime as is used for Axis and the client app does not solve the problem. Interestingly, rebuilding libxml with threads disabled
[jira] Issue Comment Edited: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556935#action_12556935 ] wtmitchell3 edited comment on AXIS2C-884 at 1/9/08 1:21 PM: -- Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I tried disabling parser_reset for all the terminations except the last. It turns out that this can still crash libxml2 in getGlobalState when issued from a thread different from the initial thread. (This is essentially the same as the traceback above when the parser cleanup was issued after each operation and the parser re-initialized for the next operation.) ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80e98b() msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int nBlockUse=0, const char * szFileName=0x239c, int nLine=40631000) Line 268 + 0x15 bytesC++ msvcr80d.dll!malloc(unsigned int nSize=16744212) Line 154 + 0x15 bytes C++ libxml2.dll!xmlGetGlobalState() Line 570 C 0001() I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free, or it may appear as a standalone crash in xmlGetGlobalState with no calling information available. So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple initializations or multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset. In a true multi-threaded case, the only way for the application to be assured a way to cleanup the libxml parser is if new entry points are created so that the application can perform the initialization in a persistent thread, and not allow the parser initialization to happen in just whichever thread happens to first create a stub/svc client. was (Author: wtmitchell3): Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I have verified that one can set this option back to true on the last termination and libxml2 is not upset to be terminating in a different thread than the initial main thread, even when the main thread no longer exists. I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free. So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset. Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell Attachments: axis2.trace, desc_builder_diff.txt In a multithreaded application,
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556935#action_12556935 ] Bill Mitchell commented on AXIS2C-884: -- Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I have verified that one can set this option back to true on the last termination and libxml2 is not upset to be terminating in a different thread than the initial main thread, even when the main thread no longer exists. I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free. So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset. Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell Attachments: axis2.trace, desc_builder_diff.txt In a multithreaded application, if the stub/svc client is freed in a thread different from that used when the svc client was built, libxml crashes. The trace below shows the information available from a release build with debug information embedded. I have verified this is not an effect of combining debug and release C runtimes, or different versions of the C runtime. Rebuilding all the libxml related dlls with the same runtime as is used for Axis and the client app does not solve the problem. Interestingly, rebuilding libxml with threads disabled does make the crash go away. But the default build of libxml commonly available has native threads enabled, and building without thread support may make the library not thread safe. By adding debug trace statements in the axis2.trace file, I have verified that the xml_reader being torn down when the crash happens is the one used to read the axis2.xml file when the configuration was first read. (axis2.trace file attached.) Looking at the code in libxml, it appears that libxml decides to close the reader using an internal close routine intended for closing compressed channels through zlib. Apparently the C runtime library returns a -1 EOF status when closing a file opened for read. The close routine, gzio.c in zlib, treats this as an error, and when libxml attempts to report the error and determines that it is in a different thread, things really go downhill fast. I have not isolated why the EnterCriticalSection call crashes in the system, but it does. One way to avoid the problem would be to guarantee that the stub/svc client is freed in the same thread as created it. In my multithreaded client application, though, I work hard to share the stub across threads deliberately to reduce the number of distinct service clients and the associated demand on the server. Windows call traceback at time of crash: ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr80.dll!78134d09() ntdll.dll!7c910e91() ntdll.dll!7c9106eb() msvcr80.dll!78134d83() ntdll.dll!7c90104b() libxml2.dll!xmlGetGlobalState() Line 570 C libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* schannel=0x, void (void *, const char *, no type)* channel=0x, void * data=0x, void * ctx=0x, void * nod=0x, int domain=8, int code=0, xmlErrorLevel level=XML_ERR_ERROR, const char * file=0x, int line=0, const char * str1=0x00c5d420, const
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556569#action_12556569 ] Bill Mitchell commented on AXIS2C-884: -- To isolate what kind of fix might work for the multithreading case, for testing I commented out the xmlInitParser() and xmlCleanupParser() calls and moved these into the application threads. If these calls are issued once at the start of the application and once at the end, all works well. The same is not true when attempting to use libxml2 serially in multiple threads. In particular, I tried creating and freeing the stub around each SOAP message, and performing an xmlInitParser and xmlCleanupParser around each use. Even in the application where mutex's can ensure that the xmlCleanupParser() completes before an xmlInitParser() is issued, and the use_counts are maintained under mutex to avoid race conditions, the first time libxml2 is initialized in a second thread after being freed in the first thread, the crash in xmlGetGlobalState reappears. See the traceback below, as well as relevant trace lines from my application trace. ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80e98b() msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int nBlockUse=0, const char * szFileName=0x2220, int nLine=67225284) Line 268 + 0x15 bytesC++ msvcr80d.dll!malloc(unsigned int nSize=17792788) Line 154 + 0x15 bytes C++ libxml2.dll!xmlGetGlobalState() Line 570 C [EMAIL PROTECTED]: | | | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell Attachments: axis2.trace, desc_builder_diff.txt In a multithreaded application, if the stub/svc client is freed in a thread different from that used when the svc client was built, libxml crashes. The trace below shows the information available from a release build with debug information embedded. I have verified this is not an effect of combining debug and release C runtimes, or different versions of the C runtime. Rebuilding all the libxml related dlls with the same runtime as is used for Axis and the client app does not solve the problem. Interestingly, rebuilding libxml with threads disabled does make the crash go away. But the default build of libxml commonly available has native threads enabled, and building without thread support may make the library not thread safe. By adding debug trace statements in the axis2.trace file, I have verified that the xml_reader being torn down when the crash happens is the one used to read the axis2.xml file when the configuration was first read. (axis2.trace file attached.) Looking at the code in libxml, it appears that libxml decides to close the reader using an internal close routine intended for closing compressed channels through zlib. Apparently the C runtime library returns a -1 EOF status when closing a file opened for read. The close routine, gzio.c in zlib, treats this as an error, and when libxml attempts to report the error and determines that it is in a different thread, things really go downhill fast. I have not isolated why the EnterCriticalSection call crashes in the system, but it does. One way to avoid the problem would be to guarantee that the stub/svc client is freed in the same thread as created it. In my multithreaded client application,
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[
https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556568#action_12556568
]
Bill Mitchell commented on AXIS2C-884:
--
I modified my client application to create and reuse service stubs separately
within each thread. Using just one thread to with multiple service stubs to
different URLs, I saw a similar libxml2 crash when the stub / svc clients are
freed. See the traceback below:
msvcr80d.dll!CheckBytes(unsigned char * pb=0xfeeefee8, unsigned char
bCheck='Ã', unsigned int nSize=3) Line 1654 + 0x7 bytes C++
msvcr80d.dll!_free_dbg_nolock(void * pUserData=0xfeeefeee, int
nBlockUse=1) Line 1257 + 0x17 bytesC++
msvcr80d.dll!_free_dbg(void * pUserData=0xfeeefeee, int nBlockUse=1) Line
1220 + 0xd bytesC++
msvcr80d.dll!free(void * pUserData=0xfeeefeee) Line 1178 + 0xb bytes
C++
libxml2.dll!xmlCharEncCloseFunc(_xmlCharEncodingHandler *
handler=0x036f0760) Line 2115 + 0xc bytes C
libxml2.dll!xmlFreeParserInputBuffer(_xmlParserInputBuffer *
in=0x036eace8) Line 2204 + 0xc bytes C
libxml2.dll!xmlFreeInputStream(_xmlParserInput * input=0x036fb020) Line
1269 + 0xb bytes C
libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x036ead98) Line 1679
+ 0x9 bytes C
libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x036f4d98) Line
2196 + 0xc bytes C
axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader *
parser=0x036fbc60, const axutil_env * env=0x0183ce10) Line 503 + 0x9 bytes C
axis2_parser.dll!axiom_xml_reader_free(axiom_xml_reader *
parser=0x036fbc60, const axutil_env * env=0x0183ce10) Line 35 C
axiom.dll!axiom_stax_builder_free(axiom_stax_builder *
om_builder=0x036fa788, const axutil_env * env=0x0183ce10) Line 885 C
axiom.dll!axiom_soap_builder_free(axiom_soap_builder *
soap_builder=0x036fa930, const axutil_env * env=0x0183ce10) Line 189 C
axiom.dll!axiom_soap_envelope_free(axiom_soap_envelope *
soap_envelope=0x036fb748, const axutil_env * env=0x0183ce10) Line 168C
axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x036e8658,
const axutil_env * env=0x0183ce10) Line 374 C
axis2_engine.dll!axis2_op_ctx_free(axis2_op_ctx * op_ctx=0x03700950, const
axutil_env * env=0x0183ce10) Line 165 C
axis2_engine.dll!axis2_op_client_free(axis2_op_client *
op_client=0x03700868, const axutil_env * env=0x0183ce10) Line 615 C
axis2_engine.dll!axis2_svc_client_free(axis2_svc_client *
svc_client=0x01864028, const axutil_env * env=0x0183ce10) Line 1287 C
axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x0186c630, const
axutil_env * env=0x0183ce10) Line 129C
The 0xfeeefeee is a prime indication that, when the second svc client is freed,
libxml2 is trying to access memory that it already.
Looking at the op_client.c and libxml2_reader_wrapper.c, it appear that Axis2c
issues an xmlInitParser and xmlCleanupParser call for each op_client,
apparently expecting that libxml2 will be tolerant and keep a count of users.
This does not match the libxml2 documentation, which is very insistent that it
expects one init at the beginning of the application, and one cleanup when all
access is done.
For testing, I tried modifying libxml2_reader_wrapper.c to keep a use_count and
perform the xmlInitParser only on the first call, and the xmlCleanupParser only
when all users are done:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_init( )
{
if (xml_init_count++ == 0)
{
xmlInitParser();
}
return AXIS2_SUCCESS;
}
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_cleanup()
{
if ((xml_init_count 0)
(--xml_init_count == 0))
{
xmlCleanupParser();
}
return AXIS2_SUCCESS;
}
This change remedies this second crash in msvcr80d.dll CheckBytes. But crashes
of the first type, in libxml2 xmlGetGlobalState still happen as soon as
activity occurs in multiple threads.
Seg fault in libxml when svc client torn down in a multithreaded client
---
Key: AXIS2C-884
URL: https://issues.apache.org/jira/browse/AXIS2C-884
Project: Axis2-C
Issue Type: Bug
Components: core/deployment
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml
2.6.30, libcurl
Reporter: Bill Mitchell
Attachments: axis2.trace, desc_builder_diff.txt
In a multithreaded application, if the stub/svc client is freed in a thread
different from that used when the svc client was built, libxml crashes. The
trace below shows the information available from a release build with debug
information embedded.
I have verified this is
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556572#action_12556572 ] Bill Mitchell commented on AXIS2C-884: -- To handle the multithreaded case, clearly the libxml2 documentation means what it says and there must be one initialize and one cleanup for the entire application. This means creating new entry points, say axis2_initialize() and axis2_cleanup, that the application client calls at the appropriate points. But demanding that all clients call these as appropriate means changing all the test cases, all the samples, all the documentation So, my suggestion is: (1) Add new entry points, axis2_initialize() and axis2_cleanup() that the client may call to manage the initialization and tear down itself. This would be required for correct multi-thread operation with libxml. (2) Add internal entry points, axis2_implicit_initialize, and axis2_implicit_cleanup, that op_client.c could use to accomplish the axiom_xml_reader_init() and cleanup. These routines would keep a use-count of active users, and, when there was no explicit initialize, would perform the underlying initialization only on the first use and the cleanup only when the last use was complete. Change (2) will fix the single-thread crash above by ensuring that no xmlCleanupParser is issued while any structures are still in use. And libxml2 seems to tolerate serial reuse as long as it is in a single thread. Change (1) gives the multithreaded client the chance to take control of the initialization and termination. Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell Attachments: axis2.trace, desc_builder_diff.txt In a multithreaded application, if the stub/svc client is freed in a thread different from that used when the svc client was built, libxml crashes. The trace below shows the information available from a release build with debug information embedded. I have verified this is not an effect of combining debug and release C runtimes, or different versions of the C runtime. Rebuilding all the libxml related dlls with the same runtime as is used for Axis and the client app does not solve the problem. Interestingly, rebuilding libxml with threads disabled does make the crash go away. But the default build of libxml commonly available has native threads enabled, and building without thread support may make the library not thread safe. By adding debug trace statements in the axis2.trace file, I have verified that the xml_reader being torn down when the crash happens is the one used to read the axis2.xml file when the configuration was first read. (axis2.trace file attached.) Looking at the code in libxml, it appears that libxml decides to close the reader using an internal close routine intended for closing compressed channels through zlib. Apparently the C runtime library returns a -1 EOF status when closing a file opened for read. The close routine, gzio.c in zlib, treats this as an error, and when libxml attempts to report the error and determines that it is in a different thread, things really go downhill fast. I have not isolated why the EnterCriticalSection call crashes in the system, but it does. One way to avoid the problem would be to guarantee that the stub/svc client is freed in the same thread as created it. In my multithreaded client application, though, I work hard to share the stub across threads deliberately to reduce the number of distinct service clients and the associated demand on the server. Windows call traceback at time of crash: ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr80.dll!78134d09() ntdll.dll!7c910e91() ntdll.dll!7c9106eb() msvcr80.dll!78134d83() ntdll.dll!7c90104b() libxml2.dll!xmlGetGlobalState() Line 570 C libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* schannel=0x, void (void *, const char *, no type)* channel=0x, void * data=0x, void * ctx=0x, void * nod=0x, int domain=8, int code=0, xmlErrorLevel level=XML_ERR_ERROR, const char * file=0x, int line=0, const char * str1=0x00c5d420, const char * str2=0x, const char *
[jira] Created: (AXIS2C-889) misleading error message from generated stub deserialize routine when SOAP fault received
misleading error message from generated stub deserialize routine when SOAP fault received - Key: AXIS2C-889 URL: https://issues.apache.org/jira/browse/AXIS2C-889 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Priority: Trivial As you can see from the following line from the axis2.trace file, the error message when a SOAP fault message is received instead of the expected response, is misleading in that it indicates the SOAP fault was expected, and the response message was received: [Sat Jan 05 21:32:21 2008] [error] .\adb_browseResponse.c(160) Failed in building adb object for browseResponse : Expected Fault|http://schemas.xmlsoap.org/soap/envelope/|SOAP but returned browseResponse|http://frameware.xcentrisity.com/services/ In the generated code, for example in the following code, the first qname_to_string actually computes the response received, and the qname_to_string of the _browseResponse-qname indicates the expected value. AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, Failed in building adb object for browseResponse : Expected %s but returned %s, axutil_qname_to_string(qname, env), axutil_qname_to_string(_browseResponse- qname, env)); Inverting the last two lines to read as follows would correct this problem: AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI, Failed in building adb object for browseResponse : Expected %s but returned %s, axutil_qname_to_string(_browseResponse- qname, env), axutil_qname_to_string(qname, env)); These lines appear to be at line 759 in CADBBeanTemplateSource.xsl. -- 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]
[jira] Commented: (AXIS2C-860) generated message stubs omit code for attributes in a named attribute group
[ https://issues.apache.org/jira/browse/AXIS2C-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556262#action_12556262 ] Bill Mitchell commented on AXIS2C-860: -- I downloaded the nightly build of 04/Jan/08 late yesterday and had a chance to test it today. After regenerating all the stubs from service.wsdl and recompiling the application, they all seem to work as intended, with all the expected functionality, and no manual correction anywhere. Wow. Thanks, Amila and Dimuthu for all the work. generated message stubs omit code for attributes in a named attribute group --- Key: AXIS2C-860 URL: https://issues.apache.org/jira/browse/AXIS2C-860 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Priority: Minor Attachments: service.wsdl, unrolled_attrgrp.wsdl When a message has attributes defined via an AttributeGroup, no properties are generated in the stubs that reflect the attributes. If the attributes are defined directly in the message without using a group, everything works fine. For example, in my service.wsdl file there is a response message defined, in part, by: complexType name=getExemplarResponseType complexContent restriction base=anyType sequence element name=exemplar type=fw:ExemplarType/ /sequence attributeGroup ref=fw:ResponseAttributeGroup/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType attributeGroup name=ResponseAttributeGroup attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ /attributeGroup No properties for responseCode nor ResponseMessage appear in the generated adb_getExemplarResponseType.c. If the attributes are replicated in each message rather than using an AttributeGroup, as below, the generated stub has all the properties: complexType name=getExemplarResponseType complexContent restriction base=anyType sequence element name=exemplar type=fw:ExemplarType/ /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType -- 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]
[jira] Created: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell In a multithreaded application, if the stub/svc client is freed in a thread different from that used when the svc client was built, libxml crashes. The trace below shows the information available from a release build with debug information embedded. I have verified this is not an effect of combining debug and release C runtimes, or different versions of the C runtime. Rebuilding all the libxml related dlls with the same runtime as is used for Axis and the client app does not solve the problem. Interestingly, rebuilding libxml with threads disabled does make the crash go away. But the default build of libxml commonly available has native threads enabled, and building without thread support may make the library not thread safe. By adding debug trace statements in the axis2.trace file, I have verified that the xml_reader being torn down when the crash happens is the one used to read the axis2.xml file when the configuration was first read. (axis2.trace file attached.) Looking at the code in libxml, it appears that libxml decides to close the reader using an internal close routine intended for closing compressed channels through zlib. Apparently the C runtime library returns a -1 EOF status when closing a file opened for read. The close routine, gzio.c in zlib, treats this as an error, and when libxml attempts to report the error and determines that it is in a different thread, things really go downhill fast. I have not isolated why the EnterCriticalSection call crashes in the system, but it does. One way to avoid the problem would be to guarantee that the stub/svc client is freed in the same thread as created it. In my multithreaded client application, though, I work hard to share the stub across threads deliberately to reduce the number of distinct service clients and the associated demand on the server. Windows call traceback at time of crash: ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr80.dll!78134d09() ntdll.dll!7c910e91() ntdll.dll!7c9106eb() msvcr80.dll!78134d83() ntdll.dll!7c90104b() libxml2.dll!xmlGetGlobalState() Line 570 C libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* schannel=0x, void (void *, const char *, no type)* channel=0x, void * data=0x, void * ctx=0x, void * nod=0x, int domain=8, int code=0, xmlErrorLevel level=XML_ERR_ERROR, const char * file=0x, int line=0, const char * str1=0x00c5d420, const char * str2=0x, const char * str3=0x, int int1=0, int col=0, const char * msg=0x00c5d360, ...) Line 452 + 0x5 bytes C libxml2.dll!__xmlSimpleError(int domain=8, int code=0, _xmlNode * node=0x, const char * msg=0x00c5d360, const char * extra=0x00c5d420) Line 657 + 0x2d bytes C libxml2.dll!__xmlIOErr(int domain=8, int code=0, const char * extra=0x00c5d420) Line 417 + 0x1a bytes C libxml2.dll!xmlGzfileClose(void * context=0x03301f80) Line 1155 + 0x10 bytes C libxml2.dll!xmlFreeParserInputBuffer(_xmlParserInputBuffer * in=0x03304578) Line 2207 + 0x5 bytes C libxml2.dll!xmlTextReaderClose(_xmlTextReader * reader=0x03304760) Line 2244 + 0x6 bytes C axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader * parser=0x03301e00, const axutil_env * env=0x031aa150) Line 510 C axiom.dll!axiom_stax_builder_free(axiom_stax_builder * om_builder=0x03271aa8, const axutil_env * env=0x031aa150) Line 886 C axis2_engine.dll!axis2_desc_builder_free(axis2_desc_builder * desc_builder=0x03301d58, const axutil_env * env=0x031aa150) Line 141 C axis2_engine.dll!axis2_conf_builder_free(axis2_conf_builder * conf_builder=0x03301d70, const axutil_env * env=0x031aa150) Line 128 C axis2_engine.dll!axis2_dep_engine_free(axis2_dep_engine * dep_engine=0x031aa2e8, const axutil_env * env=0x031aa150) Line 380 C axis2_engine.dll!axis2_conf_free(axis2_conf * conf=0x0330cad8, const axutil_env * env=0x031aa150) Line 328 C axis2_engine.dll!axis2_conf_ctx_free(axis2_conf_ctx * conf_ctx=0x, const axutil_env * env=0x031aa150) Line 439 C axis2_engine.dll!axis2_svc_client_free(axis2_svc_client *
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556180#action_12556180 ] Bill Mitchell commented on AXIS2C-884: -- Much as I like the source fix in my recommendation, as it does fix one symptom of the problem and frees resources, including files, sooner rather than later, I must admit it is not a complete solution. The initial crash I reported is remedied, but I still see other bizarre behavior from libxml when invoked from multiple threads. The libxml documentation indicates that it expects to be initialized once in the main thread before multithreaded operation begins. Instead, Axis2 does the initialization each time the op_client is created, which happens in my case in one of the multiple threads after application initialization. I have tried doing the initialization just once with a call to xmlInitParser() in the main application thread before any call to the Axis2 routines, but this reintroduces the crash in xmlGetGlobalState. So I can't honestly recommend that moving the xmlInitParser call earlier, say when the first environment was created which might happen in the application main thread, would alleviate any problem. This suggests that libxml is not as thread-safe as we would like, and that each thread must create and use its own set of svc clients, instead of sharing them in a connection pool. Of course, the guththila parser does not suffer from this particular thread problem. Seg fault in libxml when svc client torn down in a multithreaded client --- Key: AXIS2C-884 URL: https://issues.apache.org/jira/browse/AXIS2C-884 Project: Axis2-C Issue Type: Bug Components: core/deployment Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml 2.6.30, libcurl Reporter: Bill Mitchell Attachments: axis2.trace, desc_builder_diff.txt In a multithreaded application, if the stub/svc client is freed in a thread different from that used when the svc client was built, libxml crashes. The trace below shows the information available from a release build with debug information embedded. I have verified this is not an effect of combining debug and release C runtimes, or different versions of the C runtime. Rebuilding all the libxml related dlls with the same runtime as is used for Axis and the client app does not solve the problem. Interestingly, rebuilding libxml with threads disabled does make the crash go away. But the default build of libxml commonly available has native threads enabled, and building without thread support may make the library not thread safe. By adding debug trace statements in the axis2.trace file, I have verified that the xml_reader being torn down when the crash happens is the one used to read the axis2.xml file when the configuration was first read. (axis2.trace file attached.) Looking at the code in libxml, it appears that libxml decides to close the reader using an internal close routine intended for closing compressed channels through zlib. Apparently the C runtime library returns a -1 EOF status when closing a file opened for read. The close routine, gzio.c in zlib, treats this as an error, and when libxml attempts to report the error and determines that it is in a different thread, things really go downhill fast. I have not isolated why the EnterCriticalSection call crashes in the system, but it does. One way to avoid the problem would be to guarantee that the stub/svc client is freed in the same thread as created it. In my multithreaded client application, though, I work hard to share the stub across threads deliberately to reduce the number of distinct service clients and the associated demand on the server. Windows call traceback at time of crash: ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr80.dll!78134d09() ntdll.dll!7c910e91() ntdll.dll!7c9106eb() msvcr80.dll!78134d83() ntdll.dll!7c90104b() libxml2.dll!xmlGetGlobalState() Line 570 C libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* schannel=0x, void (void *, const char *, no type)* channel=0x, void * data=0x, void * ctx=0x, void * nod=0x, int domain=8, int code=0, xmlErrorLevel level=XML_ERR_ERROR, const char * file=0x, int line=0, const char * str1=0x00c5d420, const char * str2=0x, const char * str3=0x, int int1=0, int col=0, const char * msg=0x00c5d360, ...) Line 452 + 0x5 bytes
[jira] Commented: (AXIS2C-849) Generated stub for SimpleType List of String returns no contents
[ https://issues.apache.org/jira/browse/AXIS2C-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555246#action_12555246 ] Bill Mitchell commented on AXIS2C-849: -- Great, Dimuthu. I rebuilt the stubs, adapted my client to the changed names, and everything worked fine. I only used strtok() because the Microsoft Visual Studio documentation suggested it was thread safe, just not usable for different strings at the same time. That may be unique to Microsoft, though. Regardless of whether it is thread-safe, you are correct that it is not a good idea in a library routine where the client might be using strtok for his own purposes. So avoiding its use is a definite improvement. Generated stub for SimpleType List of String returns no contents Key: AXIS2C-849 URL: https://issues.apache.org/jira/browse/AXIS2C-849 Project: Axis2-C Issue Type: Improvement Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Attachments: adb_MethodListType.c, adb_MethodListType.h, adb_MethodListType.orig.c, simple_type_list.tar.gz, unrolled.wsdl The WSDL fragment below illustrates a SimpleType declared as a list of strings that is returned as an attribute in a response message. In the generated stubs, the deserialize routine in adb_getExemplarResponse.c nicely expects the MethodListType to deserialize the attribute string into an object and stores the returned MethodListType object as a property of the response. Yet the generated adb_MethodListType.c doesn't have any properties and has essentially empty routines for the deserialize_from_string and serialize_to_string procedures. simpleType name=MethodListType list itemType=string/ /simpleType ... element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Commented: (AXIS2C-855) Generated stubs leak memory associated with string/array properties
[
https://issues.apache.org/jira/browse/AXIS2C-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12555011
]
Bill Mitchell commented on AXIS2C-855:
--
I regenerated with a new build and verified that the reset code is now correct
in all of them. Thanks.
Generated stubs leak memory associated with string/array properties
---
Key: AXIS2C-855
URL: https://issues.apache.org/jira/browse/AXIS2C-855
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl
Reporter: Bill Mitchell
The generated adb_type_free methods leak memory associated with string or
array properties, i.e., any property with associated memory. The free
routine correctly calls the reset routine to actually free the memory. But
the reset routine has an incorrectly written guard to verify its passed
pointer, such that it always returns without freeing anything.
Here is a sample of the generated reset routine for a constraint property
that is a string.
axis2_status_t AXIS2_CALL
adb_conditionInstance_type0_reset_constraint(
adb_conditionInstance_type0_t* _conditionInstance_type0,
const axutil_env_t *env)
{
int i = 0;
int count = 0;
void *element = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
AXIS2_PARAM_CHECK(env-error, _conditionInstance_type0,
AXIS2_FAILURE);
if(NULL != _conditionInstance_type0)
{
return AXIS2_FAILURE;
}
if(_conditionInstance_type0-property_constraint != NULL)
{
AXIS2_FREE(env- allocator,
_conditionInstance_type0-property_constraint);
_conditionInstance_type0-property_constraint = NULL;
}
_conditionInstance_type0-is_valid_constraint = AXIS2_FALSE;
return AXIS2_SUCCESS;
}
As you can see, after using AXIS2_PARAM_CHECK to return an error if the
passed _conditionInstance_type0 pointer is zero, the generated code then
returns an error if the pointer is nonzero. Although one could simply fix
the != comparison to be ==, the second test is redundant thanks to the
AXIS2_PARAM_CHECK and could best be removed entirely.
This error is present in all of the adb_type_reset routines, but causes a
memory leak only for types represented by allocated memory.
--
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]
[jira] Reopened: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[
https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell reopened AXIS2C-848:
--
On a more recent build, I have verified that there is no compilation error in
the generated stub for the unrolled.wsdl. Thanks, Dimuthu. So I tried going
back to the original service.wsdl to see if all the problems are fixed there as
well. Although in the case of anonymous types the code is correct, there is
still a problem with named types.
The new code for the anonymous type in adb_instance_type1.c is:
{
axiom_node_t *current_property_node = current_node;
current_node = axiom_node_get_next_sibling(current_node, env);
axiom_node_detach(current_property_node, env);
axutil_array_list_add_at(arr_list, env, i,
(void*)current_property_node);
}
When I generate effectively the same service from service.wsdl, I see in
adb_InstanceType.c:
{
axiom_node_t *current_property_node = current_node;
current_node = axiom_node_get_next_sibling(current_node, env);
axiom_node_detach(current_property_node, env);
axutil_array_list_add_at(arr_list, env, i,
(void*)current_property_node);
status = adb_InstanceType_set_extraElement(_InstanceType, env,
current_property_node);
}
The extra _set_extraElement call doesn't work, and fortunately doesn't compile.
Generated stub for unbounded sequence of type any does not pass any elements
to client
--
Key: AXIS2C-848
URL: https://issues.apache.org/jira/browse/AXIS2C-848
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila parser,
libcurl, using WSDL2C from nightly build of 12/19/07
Reporter: Bill Mitchell
Assignee: Dimuthu Gamage
Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c,
adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c,
case26.tar.gz, unrolled.wsdl
Where a complexType is defined as an unbounded sequence of type any, as in
the wsdl fragment below, the generated stub implements no code to handle the
elements themselves, with the comment that it is imposible to handle the
request type - so please do it manually. Yet, for the same sequence with a
maxOccurs = 1, the generated stub is perfectly willing to return the single
element of type any in a property of type axiom_node_t *, by detaching the
node from the response document and making it a property of the stub object.
It would be useful and reasonable in the case of multiple any items to return
an array of axiom_node_t*, by detaching each from the response message, as is
done in the case of a single any element.
element name=getExemplarResponse
complexType
complexContent
restriction base=anyType
sequence
element name=exemplar minOccurs=1
maxOccurs=1
complexType
sequence
any namespace=##local
minOccurs=1 maxOccurs=unbounded/
/sequence
attribute name=handle
type=string use=required/
/complexType
/element
/sequence
attribute name=responseCode type=integer
use=optional default=0/
attribute name=responseMessage type=string
use=optional/
attribute name=supportedMethods
type=fw:MethodListType use=optional/
/restriction
/complexContent
/complexType
/element
--
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]
[jira] Updated: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-848: - Attachment: service.wsdl Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Assignee: Dimuthu Gamage Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c, case26.tar.gz, service.wsdl, unrolled.wsdl Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Created: (AXIS2C-860) generated message stubs omit code for attributes in a named attribute group
generated message stubs omit code for attributes in a named attribute group --- Key: AXIS2C-860 URL: https://issues.apache.org/jira/browse/AXIS2C-860 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Priority: Minor Attachments: service.wsdl, unrolled_attrgrp.wsdl When a message has attributes defined via an AttributeGroup, no properties are generated in the stubs that reflect the attributes. If the attributes are defined directly in the message without using a group, everything works fine. For example, in my service.wsdl file there is a response message defined, in part, by: complexType name=getExemplarResponseType complexContent restriction base=anyType sequence element name=exemplar type=fw:ExemplarType/ /sequence attributeGroup ref=fw:ResponseAttributeGroup/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType attributeGroup name=ResponseAttributeGroup attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ /attributeGroup No properties for responseCode nor ResponseMessage appear in the generated adb_getExemplarResponseType.c. If the attributes are replicated in each message rather than using an AttributeGroup, as below, the generated stub has all the properties: complexType name=getExemplarResponseType complexContent restriction base=anyType sequence element name=exemplar type=fw:ExemplarType/ /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType -- 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]
[jira] Updated: (AXIS2C-860) generated message stubs omit code for attributes in a named attribute group
[ https://issues.apache.org/jira/browse/AXIS2C-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-860: - Attachment: unrolled_attrgrp.wsdl service.wsdl For the attached service.wsdl, the generated stubs omit the properties for the attributes in the attribute group. For the attached unrolled_attrgrp.wsdl, that differs only by including the attributes inline instead of in a group, the generated stubs are complete. generated message stubs omit code for attributes in a named attribute group --- Key: AXIS2C-860 URL: https://issues.apache.org/jira/browse/AXIS2C-860 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Priority: Minor Attachments: service.wsdl, unrolled_attrgrp.wsdl When a message has attributes defined via an AttributeGroup, no properties are generated in the stubs that reflect the attributes. If the attributes are defined directly in the message without using a group, everything works fine. For example, in my service.wsdl file there is a response message defined, in part, by: complexType name=getExemplarResponseType complexContent restriction base=anyType sequence element name=exemplar type=fw:ExemplarType/ /sequence attributeGroup ref=fw:ResponseAttributeGroup/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType attributeGroup name=ResponseAttributeGroup attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ /attributeGroup No properties for responseCode nor ResponseMessage appear in the generated adb_getExemplarResponseType.c. If the attributes are replicated in each message rather than using an AttributeGroup, as below, the generated stub has all the properties: complexType name=getExemplarResponseType complexContent restriction base=anyType sequence element name=exemplar type=fw:ExemplarType/ /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType -- 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]
[jira] Created: (AXIS2C-861) Enable client session management through http cookies in libcurl
Enable client session management through http cookies in libcurl Key: AXIS2C-861 URL: https://issues.apache.org/jira/browse/AXIS2C-861 Project: Axis2-C Issue Type: Improvement Components: transport/http Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Many existing SOAP services maintain session context through HTTP cookies. This can be seen in the prevalence of some mechanism to enable client cookies in various SOAP stacks, including the Axis versions in Java and C++. Without re-implementing all of this in the Axis2C http transport, it would be easy and convenient to provide this support for Axis2C clients built with libcurl. Libcurl already provides the underlying cookie support, all that is needed is some mechanism to enable/disable this support with, say, the defined but unused maintain_session option. -- 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]
[jira] Updated: (AXIS2C-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-861: - Attachment: libcurl_diff The attached diff file builds upon the changes suggested in AXIS2C-830, wherein are changes to make the libcurl interface multithreaded with a separate libcurl object for each http transport sender. Building on the changes there, enabling client session management through HTTP session cookies is fairly straightforward. In the msg_ctx, we need to propagate the manage_session flag already made accessible to the client in the options. Then in axis2_libcurl_send, we need to enable the curl cookie engine if manage_session is true, and then discard all cookies if manage_session later is set false. I've included the changes from AXIS2C-830 with these, to make it easier to integrate all at once, and to avoid the problem of the line numbers changing when one is integrated without the other. The only incremental changes are to msg_ctx.c/.h and the code in axis2_libcurl.c to remember the cookie state in the curl structure and to call curl_easy_setopt as needed. Of course, a simple fix would be to enable cookie management all the time in the libcurl interface. In fact, this has been how I have been accessing a service that requires cookies for several weeks now. But since the Java and C++ implementations of Axis controlled this through the maintain_session option, it seems worthwhile to preserve the user control and enable or disable cookie management under the control of the manage_session option here. Enable client session management through http cookies in libcurl Key: AXIS2C-861 URL: https://issues.apache.org/jira/browse/AXIS2C-861 Project: Axis2-C Issue Type: Improvement Components: transport/http Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Attachments: libcurl_diff Many existing SOAP services maintain session context through HTTP cookies. This can be seen in the prevalence of some mechanism to enable client cookies in various SOAP stacks, including the Axis versions in Java and C++. Without re-implementing all of this in the Axis2C http transport, it would be easy and convenient to provide this support for Axis2C clients built with libcurl. Libcurl already provides the underlying cookie support, all that is needed is some mechanism to enable/disable this support with, say, the defined but unused maintain_session option. -- 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]
[jira] Created: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
guththila parser fails to handle escape sequences for ampersand, less than, greater than Key: AXIS2C-859 URL: https://issues.apache.org/jira/browse/AXIS2C-859 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell When an incoming message contains within text the escaped ampersand sequence, amp;, this sequence is being passed to the client as raw text without being converted to the single ampersand character. Clearly, this action must take place at the level of the parser, as only the parser knows whether it is seeing simple text, and conversion is required, or text embedded in a CDATA section, where conversion is not allowed. I have tested the build with the libxml parser, and of course the libxml parser behaves correctly: the text passed to the client contains only the single ampersand character, not the escaped sequence. (See section 2.4 of XML 1.0 spec.) Looking at the code, I expect the same problem occurs with all escaped sequences, less than and greater than as well as ampersand, on both input and output. I also don't see where CDATA sections are handled, but as I am not seeing CDATA in the messages from the service I am hitting, I have not tested this case. -- 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]
[jira] Updated: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-857: - Priority: Minor (was: Major) guththila parser drops xml:id attributes from incoming elements --- Key: AXIS2C-857 URL: https://issues.apache.org/jira/browse/AXIS2C-857 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Priority: Minor The XML specification allows an element to carry an xml:id attribute without the xml namespace being declared explicitly. In fact, if the xml namespace is declared, it must match http://www.w3.org/XML/1998/namespace. When the namespace is not declared explicitly, it appears that the guththila parser discards the incoming xml:id attributes without including them in the om. For example, I receive a response message from a service that begins: env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:fw=http://frameware.xcentrisity.com/services/; env:Body fw:getExemplarResponse responseMessage=master exemplar provided. name=customer supportedMethods=browse browseNext browsePrevious create update delete retrieve exemplar handle=master cr-customer-record xml:id=Q375 type=xsd:string cr-customer-id xml:id=Q376 type=xsd:string /cr-customer-id ... When linked with libxml, the client code sees two attributes, a type attribute and an xml:id attribute, attached to the element nodes. When linked with the guththila parser, only the type attribute is present. -- 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]
[jira] Created: (AXIS2C-855) Generated stubs leak memory associated with string/array properties
Generated stubs leak memory associated with string/array properties
---
Key: AXIS2C-855
URL: https://issues.apache.org/jira/browse/AXIS2C-855
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl
Reporter: Bill Mitchell
The generated adb_type_free methods leak memory associated with string or
array properties, i.e., any property with associated memory. The free routine
correctly calls the reset routine to actually free the memory. But the reset
routine has an incorrectly written guard to verify its passed pointer, such
that it always returns without freeing anything.
Here is a sample of the generated reset routine for a constraint property that
is a string.
axis2_status_t AXIS2_CALL
adb_conditionInstance_type0_reset_constraint(
adb_conditionInstance_type0_t* _conditionInstance_type0,
const axutil_env_t *env)
{
int i = 0;
int count = 0;
void *element = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
AXIS2_PARAM_CHECK(env-error, _conditionInstance_type0,
AXIS2_FAILURE);
if(NULL != _conditionInstance_type0)
{
return AXIS2_FAILURE;
}
if(_conditionInstance_type0-property_constraint != NULL)
{
AXIS2_FREE(env- allocator,
_conditionInstance_type0-property_constraint);
_conditionInstance_type0-property_constraint = NULL;
}
_conditionInstance_type0-is_valid_constraint = AXIS2_FALSE;
return AXIS2_SUCCESS;
}
As you can see, after using AXIS2_PARAM_CHECK to return an error if the passed
_conditionInstance_type0 pointer is zero, the generated code then returns an
error if the pointer is nonzero. Although one could simply fix the !=
comparison to be ==, the second test is redundant thanks to the
AXIS2_PARAM_CHECK and could best be removed entirely.
This error is present in all of the adb_type_reset routines, but causes a
memory leak only for types represented by allocated memory.
--
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]
[jira] Created: (AXIS2C-856) axiom_element_get_children() code behavior does not match header description
axiom_element_get_children() code behavior does not match header description Key: AXIS2C-856 URL: https://issues.apache.org/jira/browse/AXIS2C-856 Project: Axis2-C Issue Type: Bug Components: xml/om Affects Versions: 1.1.0 Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Priority: Minor The comments in axiom_element.h describing the behavior of axiom_element_get_children indicate that the returned interator is owned by the user and must be freed by the user. In fact, the code implements this function like axiom_element_get_children_with_qname, where the iterator is owned by the element and is freed when the om is freed. Obviously if the user follows the instructions in the .h file and frees the iterator, the memory may be reused before the om structure is freed, at which time things go rapidly downhill. Here are the current comments: /** * returns a list of children iterator * iterators free function must be called by user */ AXIS2_EXTERN axiom_children_iterator_t *AXIS2_CALL axiom_element_get_children( axiom_element_t * om_element, const axutil_env_t * env, axiom_node_t * element_node); I suggest this should read: /** * returns a list of children iterator * returned iterator is freed when om element struct * is freed * iterators reset function must be called by user */ AXIS2_EXTERN axiom_children_iterator_t *AXIS2_CALL axiom_element_get_children( ... -- 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]
[jira] Commented: (AXIS2C-838) For a ComplexType with attributes but no child entities, the generated stub fails to compile
[
https://issues.apache.org/jira/browse/AXIS2C-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554620
]
Bill Mitchell commented on AXIS2C-838:
--
Thanks, Dimuthu. I have verified this fix by rebuilding all the stubs with the
latest nightly build, and I see no instance of this problem.
For a ComplexType with attributes but no child entities, the generated stub
fails to compile
Key: AXIS2C-838
URL: https://issues.apache.org/jira/browse/AXIS2C-838
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, VisualStudio 2005
Reporter: Bill Mitchell
Assignee: Dimuthu Gamage
Priority: Minor
Attachments: unrolled.wsdl
In my wsdl file, there is a request message of the form:
element name=delete
complexType
attribute name=name type=string use=required/
attribute name=handle type=string use=required/
attribute name=exemplarHandle type=string
use=required/
attribute name=userId type=string use=optional/
attribute name=userName type=string use=optional/
/complexType
/element
In the generated stub, adb__delete.c, the deserialize function gets a
compilation error because current_element is used but not defined. It is
used in the code fragment that verifies the qname of the received object
against the expected qname:
current_element = (axiom_element_t
*)axiom_node_get_data_element(parent, env);
qname = axiom_element_get_qname(current_element, env,
parent);
if (axutil_qname_equals(qname, env, __delete- qname))
{
first_node = axiom_node_get_first_child(parent,
env);
}
else
{
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI,
Failed in building adb object for delete :
Expected %s but returned %s,
axutil_qname_to_string(qname, env),
axutil_qname_to_string(__delete- qname, env));
return AXIS2_FAILURE;
}
Obviously the workaround is to add a declaration of the current_element in
the deserialize method in each generated stub that has this problem:
axiom_element_t *current_element = NULL;
--
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]
[jira] Updated: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-848: - Attachment: adb_instance_type1.orig.c adb_instance_type1.c The attached adb_instance_type1.orig.c shows the code as generated by WSDL2C. The attached adb_instance_type1.c shows a modified version that compiles correctly and executes. The difference also illustrates fixes to another issue I reported, AXIS2C-855, that the property structures are not being released. Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Assignee: Dimuthu Gamage Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c, case26.tar.gz, unrolled.wsdl Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Commented: (AXIS2C-847) WSDL stub for sequence of multiple type any fails to compile, refers to axis2_array_list_t
[ https://issues.apache.org/jira/browse/AXIS2C-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554619 ] Bill Mitchell commented on AXIS2C-847: -- Thanks, Dimuthu. I have verified this by rebuilding stubs with the latest nightly build. WSDL stub for sequence of multiple type any fails to compile, refers to axis2_array_list_t Key: AXIS2C-847 URL: https://issues.apache.org/jira/browse/AXIS2C-847 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, nightly build of WSDL2C in Axis2 Java from 12/19/07. Reporter: Bill Mitchell Attachments: adb_instance_type2.c, adb_instance_type2.h, unrolled.wsdl Where an element contains an unbounded sequence of type any, the generated header file and source file for the element fails to compile, as they refer to a non-existent type axis2_array_list_t. Instead, they should use the type axutil_array_list_t*. To illustrate, for the response message below, WSDL2C generates a class adb_instance_type2 to represent the elements in the sequence in the response. element name=browseResponse complexType complexContent restriction base=anyType sequence element name=instance minOccurs=0 maxOccurs=unbounded complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence ` attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ /restriction /complexContent /complexType /element The generated method for adb_instance_type2_get_extraElement_at() reads: axis2_array_list_t AXIS2_CALL adb_instance_type2_get_extraElement_at( adb_instance_type2_t* _instance_type2, const axutil_env_t *env, int i); This failure does not appear when the sequence of type any is declared with maxOccurs = 1, as the generated class can then return the single axiom_node_t directly: axiom_node_t* AXIS2_CALL adb_instance_type2_get_extraElement( adb_instance_type2_t* _instance_type2, const axutil_env_t *env); This failure affects the declarations of adb_type_get_extraElement_at(), adb_type_set_extraElement_at(), adb_type_add_extraElement(), and the code in the _get_extraElement_at() routine that refers to the return value. As well the comments around adb_type_get_extraElement(), adb_type_set_extraElement(). -- 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]
[jira] Reopened: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-848: -- Thanks for addressing this, Dimuthu. We are really close to this working. When I tested the results in the nightly build, there remains one compilation error in the fix you installed. In the loop in deserialize that detaches the nodes and adds them to the array, it declares a new variable current_property_node at the point that it needs to use it. Unfortunately, as this is C code and not C++ code, the declaration needs to occur at the beginning of a block. The following is the fragment of code in question: axiom_node_t *current_property_node = current_node; current_node = axiom_node_get_next_sibling(current_node, env); axiom_node_detach(current_property_node, env); axutil_array_list_add_at(arr_list, env, i, (void*)current_property_node); In the files I am attaching, you can see the complete context. Either current_property_node needs to be declared at the start of this block, i.e., at the beginning of the for, or at the beginning of the deserialize function with all the other declarations. Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Assignee: Dimuthu Gamage Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, adb_exemplar_type0.single.c, case26.tar.gz, unrolled.wsdl Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Commented: (AXIS2C-843) Generated deserialize method does not handle complex type containing sequence of type any
[ https://issues.apache.org/jira/browse/AXIS2C-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554621 ] Bill Mitchell commented on AXIS2C-843: -- I have verified after rebuilding with the latest nightly build that none of my generated stubs now show the problem with the extraElement string being verified or generated. Thanks. Generated deserialize method does not handle complex type containing sequence of type any - Key: AXIS2C-843 URL: https://issues.apache.org/jira/browse/AXIS2C-843 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: 1.1.0 Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell Assignee: Dimuthu Gamage Attachments: adb_exemplar_type0.new.c, adb_exemplar_type0.orig.c, case25.tar.gz, unrolled.wsdl When WSDL2C generates a stub for the following response message description, it constructs a stub for entity exemplar. For this entity, it defines a single property of type axiom_node_t, the deserialize routine parses only the first of the any elements, and ignores the remainder. The second issue is that it parses the any entity only if its name is extraElement, which is not very useful as it has some name, unknown at compilation time, but which is not likely to be extraElement. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar complexType sequence any namespace=##local minOccurs=1 maxOccurs=1/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element My suggestion is that the comparison for the QName extraElement should be removed, and the property of extraElement should be an array of axiom_node_t representing all of the sequence of any entities. This impacts the deserialize and serialize routines, and the resetter method to avoid the potential memory leak. I've seen such code generated for a sequence of elements of a simple type, so it should not be too hard to generate the same code here in a complexType. -- 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]
[jira] Created: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
guththila parser drops xml:id attributes from incoming elements --- Key: AXIS2C-857 URL: https://issues.apache.org/jira/browse/AXIS2C-857 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell The XML specification allows an element to carry an xml:id attribute without the xml namespace being declared explicitly. In fact, if the xml namespace is declared, it must match http://www.w3.org/XML/1998/namespace. When the namespace is not declared explicitly, it appears that the guththila parser discards the incoming xml:id attributes without including them in the om. For example, I receive a response message from a service that begins: env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:fw=http://frameware.xcentrisity.com/services/; env:Body fw:getExemplarResponse responseMessage=master exemplar provided. name=customer supportedMethods=browse browseNext browsePrevious create update delete retrieve exemplar handle=master cr-customer-record xml:id=Q375 type=xsd:string cr-customer-id xml:id=Q376 type=xsd:string /cr-customer-id ... When linked with libxml, the client code sees two attributes, a type attribute and an xml:id attribute, attached to the element nodes. When linked with the guththila parser, only the type attribute is present. -- 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]
[jira] Commented: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554658 ] Bill Mitchell commented on AXIS2C-857: -- In the outgoing direction, when the xml:id attribute is passed back through libxml, the resulting message includes an explicit reference to the xmlns:xml namespace. So I suspect that libxml is creating an xml namespace during its parse when it sees the xml: attribute but no namespace declaration. guththila parser drops xml:id attributes from incoming elements --- Key: AXIS2C-857 URL: https://issues.apache.org/jira/browse/AXIS2C-857 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl Reporter: Bill Mitchell The XML specification allows an element to carry an xml:id attribute without the xml namespace being declared explicitly. In fact, if the xml namespace is declared, it must match http://www.w3.org/XML/1998/namespace. When the namespace is not declared explicitly, it appears that the guththila parser discards the incoming xml:id attributes without including them in the om. For example, I receive a response message from a service that begins: env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:fw=http://frameware.xcentrisity.com/services/; env:Body fw:getExemplarResponse responseMessage=master exemplar provided. name=customer supportedMethods=browse browseNext browsePrevious create update delete retrieve exemplar handle=master cr-customer-record xml:id=Q375 type=xsd:string cr-customer-id xml:id=Q376 type=xsd:string /cr-customer-id ... When linked with libxml, the client code sees two attributes, a type attribute and an xml:id attribute, attached to the element nodes. When linked with the guththila parser, only the type attribute is present. -- 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]
[jira] Updated: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-848: - Attachment: (was: adb_exemplar_type0.c) Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, adb_exemplar_type0.single.c, unrolled.wsdl Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Updated: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-848: - Attachment: adb_exemplar_type0.c In further exercising the code, I discovered another anomaly in the generated stubs. The data passed into/from the set/get_extraElement_at routines were declared to be axis2_array_list_t. Following my suggestion that we return an axiom_node_t of each element, just as is done for the single element when maxOccurs = 1, the types for these routines become axiom_node_t. I have replaced the attached adb_exemplar_type0.c to show include the change in the datatype to _set_extraElement_at, _get_extraElement_at and _add_extraElement. Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, adb_exemplar_type0.single.c, unrolled.wsdl Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Commented: (AXIS2C-812) guththila parser fails attempting to deallocate unallocated cell if xml message contains more than one namespace
[ https://issues.apache.org/jira/browse/AXIS2C-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553413 ] Bill Mitchell commented on AXIS2C-812: -- After updating through 605623 I have verified that the response messages with multiple namespaces are now accepted correctly. Thank you, Lahiru and Supun. guththila parser fails attempting to deallocate unallocated cell if xml message contains more than one namespace Key: AXIS2C-812 URL: https://issues.apache.org/jira/browse/AXIS2C-812 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows, Visual Studio 2005, guththila validating parser Reporter: Bill Mitchell Attachments: guththila_xml_parser_diff, guththila_xml_parser_diff_2 The guththila validating parser fails attempting to deallocate an unallocated cell if the xml message constains more than one namespace. The issue is that the validating parser allocates one cell of memory to hold an array of namespaces, but that the code that frees the namespaces believes that each array element is a separate cell. Thus, if the array contains more than one element, the free of the second element fails. One can see the problem when parsing a SOAP response message identifying two namespaces, e.g., one that begins: ?xml version=1.0 encoding=UTF-8 ? - env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; - env:Body ... This appears to be a problem introduced as part of fix AXIS2C-785 since 1.1.0 in the development branch; in 1.1.0 the array was not freed at all. -- 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]
[jira] Created: (AXIS2C-847) WSDL stub for sequence of multiple type any fails to compile, refers to axis2_array_list_t
WSDL stub for sequence of multiple type any fails to compile, refers to axis2_array_list_t Key: AXIS2C-847 URL: https://issues.apache.org/jira/browse/AXIS2C-847 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, nightly build of WSDL2C in Axis2 Java from 12/19/07. Reporter: Bill Mitchell Where an element contains an unbounded sequence of type any, the generated header file and source file for the element fails to compile, as they refer to a non-existent type axis2_array_list_t. Instead, they should use the type axutil_array_list_t*. To illustrate, for the response message below, WSDL2C generates a class adb_instance_type2 to represent the elements in the sequence in the response. element name=browseResponse complexType complexContent restriction base=anyType sequence element name=instance minOccurs=0 maxOccurs=unbounded complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence ` attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ /restriction /complexContent /complexType /element The generated method for adb_instance_type2_get_extraElement_at() reads: axis2_array_list_t AXIS2_CALL adb_instance_type2_get_extraElement_at( adb_instance_type2_t* _instance_type2, const axutil_env_t *env, int i); This failure does not appear when the sequence of type any is declared with maxOccurs = 1, as the generated class can then return the single axiom_node_t directly: axiom_node_t* AXIS2_CALL adb_instance_type2_get_extraElement( adb_instance_type2_t* _instance_type2, const axutil_env_t *env); This failure affects the declarations of adb_type_get_extraElement_at(), adb_type_set_extraElement_at(), adb_type_add_extraElement(), and the code in the _get_extraElement_at() routine that refers to the return value. As well the comments around adb_type_get_extraElement(), adb_type_set_extraElement(). -- 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]
[jira] Updated: (AXIS2C-847) WSDL stub for sequence of multiple type any fails to compile, refers to axis2_array_list_t
[ https://issues.apache.org/jira/browse/AXIS2C-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-847: - Attachment: adb_instance_type2.c adb_instance_type2.h unrolled.wsdl The attached .wsdl can be used to illustrate the problem, as seen in the attached instance_type2 header and c files. The command line I used to generate the stubs was: java org.apache.axis2.wsdl.WSDL2C -l c -or -d adb -wv 1.1 -s -S unrolled -u -uri unrolled.wsdl After changing every instance of axis2_array_list_t to axutil_array_list_t*, the generated stubs compiled successfully. WSDL stub for sequence of multiple type any fails to compile, refers to axis2_array_list_t Key: AXIS2C-847 URL: https://issues.apache.org/jira/browse/AXIS2C-847 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, nightly build of WSDL2C in Axis2 Java from 12/19/07. Reporter: Bill Mitchell Attachments: adb_instance_type2.c, adb_instance_type2.h, unrolled.wsdl Where an element contains an unbounded sequence of type any, the generated header file and source file for the element fails to compile, as they refer to a non-existent type axis2_array_list_t. Instead, they should use the type axutil_array_list_t*. To illustrate, for the response message below, WSDL2C generates a class adb_instance_type2 to represent the elements in the sequence in the response. element name=browseResponse complexType complexContent restriction base=anyType sequence element name=instance minOccurs=0 maxOccurs=unbounded complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence ` attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ /restriction /complexContent /complexType /element The generated method for adb_instance_type2_get_extraElement_at() reads: axis2_array_list_t AXIS2_CALL adb_instance_type2_get_extraElement_at( adb_instance_type2_t* _instance_type2, const axutil_env_t *env, int i); This failure does not appear when the sequence of type any is declared with maxOccurs = 1, as the generated class can then return the single axiom_node_t directly: axiom_node_t* AXIS2_CALL adb_instance_type2_get_extraElement( adb_instance_type2_t* _instance_type2, const axutil_env_t *env); This failure affects the declarations of adb_type_get_extraElement_at(), adb_type_set_extraElement_at(), adb_type_add_extraElement(), and the code in the _get_extraElement_at() routine that refers to the return value. As well the comments around adb_type_get_extraElement(), adb_type_set_extraElement(). -- 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]
[jira] Created: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
[jira] Updated: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-848: - Attachment: unrolled.wsdl Generated stub for unbounded sequence of type any does not pass any elements to client -- Key: AXIS2C-848 URL: https://issues.apache.org/jira/browse/AXIS2C-848 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl, using WSDL2C from nightly build of 12/19/07 Reporter: Bill Mitchell Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, adb_exemplar_type0.single.c, unrolled.wsdl Where a complexType is defined as an unbounded sequence of type any, as in the wsdl fragment below, the generated stub implements no code to handle the elements themselves, with the comment that it is imposible to handle the request type - so please do it manually. Yet, for the same sequence with a maxOccurs = 1, the generated stub is perfectly willing to return the single element of type any in a property of type axiom_node_t *, by detaching the node from the response document and making it a property of the stub object. It would be useful and reasonable in the case of multiple any items to return an array of axiom_node_t*, by detaching each from the response message, as is done in the case of a single any element. element name=getExemplarResponse complexType complexContent restriction base=anyType sequence element name=exemplar minOccurs=1 maxOccurs=1 complexType sequence any namespace=##local minOccurs=1 maxOccurs=unbounded/ /sequence attribute name=handle type=string use=required/ /complexType /element /sequence attribute name=responseCode type=integer use=optional default=0/ attribute name=responseMessage type=string use=optional/ attribute name=supportedMethods type=fw:MethodListType use=optional/ /restriction /complexContent /complexType /element -- 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]
