Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <47B9A6AA.1060703@wso2.com>
Date: Mon, 18 Feb 2008 21:09:22 +0530
From: Sanjaya Ratnaweera <sanjaya@wso2.com>
User-Agent: Icedove 1.5.0.14pre (X11/20071018)
MIME-Version: 1.0
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
Subject: Re: Issue in using 'detach' for cloning
References: <23197723.373531203252359339.JavaMail.root@hrndva-web18-z02>
 <47B8E847.3090105@wso2.com>
In-Reply-To: <47B8E847.3090105@wso2.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Samisa Abeysinghe wrote:
> Hi Bill, Kasun and others,
>    Thank you all for taking time to explain this problem in detail. 
> Looking at the ADB use case that Bill has portrayed, I am sure other 
> users too would be interested in such a case where they can 'get' form 
> one ADB type and 'set' on another ADB type.
>
>    Lets create a branch for this and try to solve the problem. Bill, 
> have you already done some work with respect to ref-count? If so we 
> can start form that.
>      I can think of the following cases that we can try to fix/implement:
>    1. Implement the ref-cout shallow copy mechanism proposed by Bill
>    2. Try and implement a deep copy version of detach (so that we can 
> detach and attach)
>    3. Implement a serailize/deserialize based deep copy
I have created a branch for this. Here's the url.

https://svn.apache.org/repos/asf/webservices/axis2/branches/c/axiomfix/

Thanks

    ~sanjaya
>
> I can look into 2 and 3.
>
> Thanks,
> Samisa...
>
> bmitchell@austin.rr.com wrote:
>> Samisa, I can't speak directly to Kasun's use case, but I can 
>> describe what prompted me to need a tree copy and/or clone method.  
>> The generated adb stubs return an object of wsdl type any to the app 
>> as a node tree, detached from the response message.  They also accept 
>> an object of wsdl type any as a node tree, to be attached to the 
>> request message.  In each case, the interface has ownership of the 
>> object, and frees the object when the interface object is freed.  So 
>> the get accessor method to the object returns a pointer to the object 
>> tree but does not transfer ownership.  The set accessor method 
>> accepts a pointer to the object tree and takes ownership of it. 
>> You are correct that cloning alone would be used in a routing app.  
>> But imagine that the app receives an object from the service, 
>> modifies it, and sends the app back to the service.  To be able to 
>> free the response interface object after processing the response, the 
>> app needs the ability to copy or clone the object to be able to late 
>> use it.  After modifying the object, the app would then pass the 
>> object back to the service in a later request.  If the app needs the 
>> ability to pass the object to the service while retaining a copy of 
>> it for later processing, it needs a copy or clone operation again as 
>> the service will discard the version that was sent when the request 
>> interface object was freed.  With a copy or a clone one can achieve 
>> the same result in different ways; a copy that allows one to 
>> configure what is copied lets the code add what it needs to a reduced 
>> tree, whereas a clone allows one to later remove or modify what is 
>> unneeded from the cloned tree. 
>> Were the generated adb interface different, the requirement for a 
>> copy would be reduced.  Say the adb interface provided an accessor 
>> method, get, that transferred ownership of the tree to the client 
>> app, and that the set method accepted a pointer to the object to be 
>> passed without freeing the tree when the request interface object was 
>> freed.  Then these copies would be eliminated, but the free of the 
>> tree after sending a request would now be the responsibility of the 
>> client app.  One would need a copy method only if the original object 
>> was a template for generating multiple objects. 
>> This may be very application specific, and I don't know how general 
>> the need is.  I do know that I encountered it, and it sounds like 
>> Kasun has a very similar requirement.  When I encountered it and 
>> found no suitable method present, I wrote one that met my needs.  But 
>> this requirement may be common enough to warrant inclusion. 
>> I'm pretty sure you are correct, there is little need for this inside 
>> the SOAP engine.  The need is driven more by the interface to axiom, 
>> at least with the adb classes.  Kasun's issue with detach losing 
>> namespace references and the tree becoming invalid arises, of course, 
>> in the context of the adb classes detaching the object from the SOAP 
>> response message, and so can arise for anyone using the 
>> service/client interface even without the adb classes. 
>> Whether addressing this involves a significant architecture change 
>> depends on the implementation.  One can implement a copy method with 
>> options for what is copied using the current interfaces, it just 
>> requires a bit of research into the intricacies of axiom_node and its 
>> friends.  A clone by way of serializing and deserializing the 
>> structure I think uses builder interfaces that are not public and 
>> would need to be included, but does not involve an architecture 
>> change.  Certainly a copy-on-write clone algorithm does involve some 
>> pervasive changes, but such an algorithm has other problems as well, 
>> already discussed. 
>> Bill
>>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa@wso2.com] Sent: Saturday, 
>> February 16, 2008 10:33 PM
>> To: Apache AXIS C Developers List
>> Subject: Re: Issue in using 'detach' for cloning
>>
>> Kasun Indrasiri wrote:
>>  
>>> Hi all,
>>>
>>> I think, through out this thread there are various possible 
>>> implementations were discussed with their pros and cons. I agreed 
>>> with Senaka that the clone method should not be the 'best' or 'fast' 
>>> one. And also Bill's ref count based implementation would suit where 
>>> we may have to explicitly worry about the performance (and lazy 
>>> coping also got its own pros and cons.)
>>> So, as Bill suggested earlier we can have several clone methods 
>>> where user can select the method according to his preference. We can 
>>> basically have one method for Shallow copy with ref counts and 
>>> another with the normal serialize/desterilize approach. (and the 
>>> lazy coping approach is also possible). Anyway it's a good move to 
>>> implement these stuff with out affecting the existing axiom.
>>>     
>>
>> IMHO, cloning is not a use case that we really need for a SOAP 
>> engine. If you are trying to use the same XML over and over again, 
>> passing it here and there, without modification, you are really 
>> routing stuff and not doing that many business logic processing.
>> I am still trying to figure out why would one want to detach and 
>> attach a node in a module or a service. If the use case is less than 
>> 10%, I do not think it is a good idea to major changes to the current 
>> AXIOM implementation that works.
>>
>> Samisa...
>>
>>
>> ---------------------------------------------------------------------
>> 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