Thanks for the vote of confidence, Senaka. My test platform lets me verify that the change fixes the problem situations without having any effect on detach operations the generated adb classes. I am able to modify the SOAP response messages from the server for testing to insert prefixes on attributes and subordinate elements and see that valid references are preserved. Being valid xml, the action of re-declaring the namespaces at the level of the detached node should have no adverse impact on Rampart/C nor Sandesha2/C. And, once integrated and released, anyone can take advantage of free performing an implied detach to make the free process more efficient.
Regards, Bill -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 12:38 PM To: [email protected] Subject: RE: Issue in using 'detach' for cloning > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
