Hello Senaka, No, existing axiom_node_detach calls do not need to change. They can all stay the same, and in general they need to stay the same in order to receive the fix that the detached tree declares all the namespaces that it references.
One of the concerns raised in the discussion, and obvious during testing, is that it is silly to redeclare the namespaces during a detach when the intent of the detach is to free the tree. So, in the internal routines where the code detached and freed the tree, I changed them to free the tree directly without a separate detach. I believe it was Samisa who agreed with my suggestion that, when free is passed a tree that is still attached, a situation not currently handled nor diagnosed as an error, free could go ahead and detach the tree before freeing it. This gives it a chance to perform a more optimized algorithm that avoids redeclaring the namespaces. Had I left the internal callers of detach as they were, the code would have performed more work, work that was unnecessary, and I thought it was important not to make their processing slower just to fix the case of trees which use namespaces declared in a high level parent node. Regards, Bill -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 10:38 AM To: Apache AXIS C Developers List Subject: Re: Issue in using 'detach' for cloning Hi Bill, I believe you have replace the axiom_node_detach logic with the implementation of axiom_node_free_tree. Does this mean that all existing axiom_node_detach followed by axiom_node_free_tree have to change? Or is it an auxiliary fix? Regards, Senaka > Bill Mitchell wrote: >> Sanjaya, you raise a question that I was going to ask Dinesh. In my >> mind, I see Jira 675 as a bug. For some xml document trees, detach >> generates a structure that is later unusable by the adb stubs that >> depend on it. As such, it could still be a candidate for inclusion in >> 1.3. And I see our other two activities, an axiom_node_copy_tree and >> axiom_node_clone_tree routines that solve some other, similar issues for >> the higher level apps as a new feature, isolated and relatively safe, >> but still at this point warranting exclusion from any current release >> activity as a new feature. >> > > If that is the case, I think we better include this in 1.3. I will have > a look as well. > > Thanks, > Samisa... >> But, it's not my decision; I think it's up to Dinesh. >> >> I did notice that you had built a branch, and I extracted a copy, >> although I think I grabbed a copy by revision number. I will be seeking >> today to take my axiom_node_copy_tree routine and include it there. >> >> Thanks, >> Bill >> >> -----Original Message----- >> From: Sanjaya Ratnaweera [mailto:[EMAIL PROTECTED] >> Sent: Thursday, February 21, 2008 8:22 AM >> To: Apache AXIS C Developers List >> Subject: Re: Issue in using 'detach' for cloning >> >> Hi bill, >> >>> I have created a branch for this. Here's the url. >>> >>> https://svn.apache.org/repos/asf/webservices/axis2/branches/c/axiomfix/ >>> >>> >> >> I have applied your patch in jira issue 675 to this branch. It failed in >> a one file. (axiom/include/axiom_element.h). It had only api doc comment >> changes. The rest was ok. >> >> Thanks >> >> ~sanjaya >> >> --------------------------------------------------------------------- >> 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] >> >> >> >> > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
