[EMAIL PROTECTED] wrote:
It should be, not trivial, but straightforward to write a clone algorithm for axiom nodes using the existing primitives. In particular, after creating a new node and data element like an original element, one should be able to attach the attributes using axiom_element_add_attribute. The attribute structures are ref counted, so they can be shared. The tricky part seems to be that one must ensure that the new cloned structure points to the very same namespace structures as the original. It is not enough that the elements point to namespaces with the same uri/prefix values. Why not? Because the attributes will point to namespace structures in the original tree, whose ref count is still 1, and the original tree may be deallocated.
So for a clone algorithm to work reasonably, one of two things must happen. (1) The cloned tree points to the very same namespace structures. When these are declared with the new elements, their ref counts will be incremented, and so they will not be deallocated when the original tree is freed. Or, (2) where the attributes point to a namespace structure, these pointers should be ref counted just like the pointers in the elements. In this case, even if the element in the new tree pointed to equivalent namespace values in new structures, the namespaces would not disappear under the attributes until the attributes themselves were released, because the ref counts on the namespaces would keep them around.
I think I've uncovered some minor issues with the namespace handling in om_element.c that make (1) difficult to achieve. I will detail them in a Jira issue shortly. I want to develop a test case that verifies what I think I see reading the code.
But Kasun raises some related issues with axiom_detach_node, issues that are not limited to his application. The generated adb classes now use axiom_node_detach when handling an element of type any, where the wsdl does not provide any further detail about the subordinate element structure. Now, imagine that the service attaches namespace prefixes to elements or attributes in the subtree of this any object. And further imagine that the xml namespace declaration is attached to a higher element, say the soap body or the child of the soap body. Then the adb object will detach the subtree, and this subtree will have pointers to the namespaces in the soap response tree. This is okay if the object is used and immediately discarded, because the soap response message is retained until the next operation. But if the client issues additional service requests, while expecting the adb object structures to still be valid until they are freed, the client app will see the same problems that Kasun raises.
To work correctly, axiom_node _detach must meet either requirement (1) or (2) above, just like cloning. Either (1) every namespace referenced in the detached subtree but declared at a higher level must now be declared at the root of the detached tree as well, so that their ref counts will now be incremented to keep the namespaces around. Or (2) the pointers to namespaces in the attributes structures need to be included in the namespace ref counts. At least in the context of my own application, I should be able to verify this with a clever test case.
This description may not be clear to anyone without test cases and stepping through the code. I hope it is. What I see here is that Kasun has raised a real issue with axiom_node_detach that impacts the generated stub classes.
I think I understand your concerns as well as the issue raised by Kasun.
If we think that fixing detach would fix this problem, then we can
consider fixing detach related problems by introducing deep copy of
namespaces in case of detaching. A workaround for the time being would
be to use serialize_sub_tree on the node to be detached and then build
the OM again form the serialized string, and you have a clone of that
sub tree - not that efficient - but works - it is a hack.
However, reading your mail, I do agree with you that using ref counts
would solve the problem. It is a bit tricky to implement due to the
assumptions that we may have made in handling the ref counts right now,
but still that would be possible. At the moment, the ref counts are used
solely to help resolve memory leak problems. If we are to use ref count
for cloning, we have to ensure that the current assumptions are not
broken or fixed to live with new cloning logic.
Samisa...
Bill Mitchell
--------------------------------------------------------------------------------------------
From: Kasun Indrasiri [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 13, 2008 12:03 AM
To: Apache AXIS C Developers List
Subject: Issue in using 'detach' for cloning
Hi,
-There is an issue in axiom_node_detach function which is related to
namespaces. Once we detach a child node from a root node and then free the
allocated memory for root node, the associated namespace for the detached node
is also freed.
For e.g. If we try to axiom_node_to_string -> it prints 'null' . But we can
get any other attribute (local name or text) from the detached node.
- And also for cloning nodes, we should have a better approach than 'detach'.
Because, detach remove the node from the original node.
Thanks,
Kasun
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
