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...
[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]
