axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: Issue in using 'detach' for cloning
Date Thu, 14 Feb 2008 08:53:40 GMT 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.


> Bill Mitchell
> --------------------------------------------------------------------------------------------
> From: Kasun Indrasiri [] 
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message