> 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.
+1, Bill, That a great piece of work. I was curious as there are several apache sub projects such as Rampart/C and Sandesha2/C which would assume that the existing API is preserved. I was noticing several fixes spreading throughout the code where you replace every detach() followed by free_tree() with a single free_tree() and was wondering, whether you demand that the existing API switch to the newer after the fix. Regards, Senaka > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
