axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <sen...@wso2.com>
Subject RE: Issue in using 'detach' for cloning
Date Thu, 21 Feb 2008 18:37:40 GMT
> 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:senaka@wso2.com]
> 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:sanjaya@wso2.com]
>>> 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: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message