+1, Senaka
> 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 can look into 2 and 3. > > Thanks, > Samisa... > > [EMAIL PROTECTED] 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:[EMAIL PROTECTED] >> 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: [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]
