axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Issue in using 'detach' for cloning
Date Fri, 15 Feb 2008 00:56:35 GMT
Samisa, I did think some more today about your suggestion to serialize and deserialize to accomplish
a clone operation.  When I first ran into this requirement to copy an axiom subtree in my
application, I investigated writing something to accomplish a clone this way.  While I was
researching whether enough entry points were public to accomplish this in the client app,
I realized that I needed more than a strict clone.  I also wanted something that would let
me copy the element tree without the attributes nor the text values, and something to copy
the element tree with the text values but without the attributes.  With a complete clone,
I would then need to run the tree to remove the extra stuff I didn't need.  

Thinking about the terminology, though, I realized that a clone may be exactly what some users
want.  The difference is that a copy, along the lines I suggest, would share the attributes.
 This is fine for most purposes, and is very efficient.  But if the application then found
an attribute and modified its value, it would modify the value in both the original and the
cloned tree.  Obviously the code could avoid this anomaly by deleting the attribute from the
cloned tree and creating a new attribute with the new value, breaking the link between the
two trees.  But this would not be obvious to someone who used a method named clone.  

So I'm beginning to think there should be two functions, one is a shallow copy of all the
data elements and text values, sharing the attributes and namespaces, the second is a true
clone of all the structures throughout the tree.  And certainly you are right that the easiest
way to implement clone as a deep copy is to serialize the tree and deserialize it into a new

Kasun, do you think you really need a clone of the tree? Are you intending to find attributes
in the tree and modify their values?  Are does a copy of the tree suffice, where you could
delete the attributes you don't want or add new ones, but where modifying the value of an
existing attribute might modify the original?


-----Original Message-----
From: [] 
Sent: Thursday, February 14, 2008 7:09 AM
Subject: RE: Issue in using 'detach' for cloning

Good, Samisa, I did explain it clearly enough.  The fact that an attribute may contain a pointer
to a namespace without the pointer being included in the namespace ref count strikes one at
first glance as odd.  But it works, if and only if, the same namespace structure is declared
for one of the parent elements of the attribute. So the current design, where the attribute
does not directly participate in incrementing and freeing the namespace structures can be
made to work, but it's fragile.  And the primary question is whether we want to keep this

If we want to keep this architecture, I see two suggestions to fixing the issue with detach
without a deep clone of the namespaces.  After all, cloning the namespaces would mean new
structures, and all the namespace pointers in the subtree would need to be updated to the
cloned values.  Either we could run the subtree to ensure that every namespace pointer in
the subtree that refers to a namespace declared above the subtree is declared again at the
root of the subtree.  Or we could just run through the parents of the root of the subtree,
and for any namespaces associated with the parents re-declare them at the subtree root, taking
into account that only one namespace can be in-scope for any particular prefix.  Either way,
declaring the namespace structure again at the subtree root will cause its ref-count to be
incremented and the structure not freed until the detached subtree is freed.  The second approach
may cause some namespaces to be declared at the root that are never used by the subtree, but
it has a simple logic of gathering up all the namespaces that are in scope at that point in
the tree, and re-declaring them.  

So the current architecture can be kept without too much work.  

To show how it's fragile, one of the mistakes I made in trying to write a clone routine was
that I determined the default namespace at the source root using axiom_element_get_default_namespace,
and then used axiom_element_declare_default_namespace to declare the same namespace in the
cloned root.  Well, declare_default_namespace accepts a URI, not a namespace pointer, so the
new cloned tree pointed to a new namespace structure for the default namespace, while attributes
in the cloned subtree pointed to the original namespace structure.  

We all understand ref counts and with some effort we can go through the code and make sure
that every pointer to a namespace either in an element or in an attribute is included in its
ref count.  This would, IMHO, create a more robust structure.  Implementing this is a little
error prone, though, and there is some risk of getting it wrong the first time.  Re-declaring
all the in-scope namespaces at the detached subtree root is easier to implement, and I think
is still sufficient to allow a clone algorithm to work by cloning just the elements while
sharing the namespaces and attributes through their ref counts.  


-----Original Message-----
From: Samisa Abeysinghe [] 
Sent: Thursday, February 14, 2008 3:54 AM
To: Apache AXIS C Developers List
Subject: Re: Issue in using 'detach' for cloning wrote:
> ...  
> 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.  
> 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.  

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:

View raw message