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