Supun, I understood this to be a side effect of an implementation decision. I raised the question to try to understand the history and rationale. As illustrated in Samisa's code fragment, it yields an application interface that is awkward to use. When using axiom_element_create, it is difficult for the caller to know whether the namespace structure was included in the tree, and so is valid and can be used to create another element, or was freed by axiom as a duplicate value, and so is no longer a valid pointer and cannot be reused. As it stands, this interface creates fragile apps, as using a namespace for consecutive element creations can be safe and valid, and a later change somewhere else in the code can make them invalid.
Similarly, for axiom_element_set_namespace, it is difficult for the caller to know whether the namespace structure was included in the tree, and will be freed when the tree is freed, or was not declared in the tree and so will not be freed unless the caller frees it. The generated adb stubs go to a fair amount of work to avoid the situation by maintaining their own hash of namespaces they have declared so they can ensure they create only one namespace structure for each distinct value and use it everywhere. I can try to expand on the comments in axiom_element.h, as part of the fix to detach to preserve the namespaces, to clarify the current interface. Bill -----Original Message----- From: Supun Kamburugamuva [mailto:[EMAIL PROTECTED] Sent: Monday, February 18, 2008 12:54 AM To: Apache AXIS C Developers List Subject: Re: axiom_element_create method inconsistency with namespaces Hi Samisa, As I have understood this problem, I wouldn't want to call this a bug. This is rather a side effect of an implementation decision. Usually when an object is set to the axiom it is considered as the responsibility of axiom to free it. Name spaces are also treated in the same way. When the first name space object is set to the node tree it becomes a part of the node tree and most importantly the pointer to this name space object is valid as long as the node tree exists. So we can use the same name space object again to create another element. When we give this name space to create another element, create method doesn't free this name space because it is the original name space. When we create another name space object with the same values as the previous name space and create another element under the original element, element create method free this new name space object. The reason is that now the node tree has a name space and there is no need to keep another name space with the same values. Also axiom free this name space because it is considered that freeing the name space is the responsibility of the axiom. So we can see that two name spaces are treated in different ways by axiom. One is not freed through out the life time of the node tree and other name space is freed immediately. When the name space is freed the pointer is set to NULL inside the axiom element create method. But this NULL value is assigned to a copy of the pointer (pass by value). So this change is not visible to outside. Regards, Supun.. On Feb 17, 2008 6:05 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: > Hi Supun, > At a glance, it looks to me as if there is a bug somewhere. I will > write some code and investigate further. > > Thanks, > Samisa... > > > Supun Kamburugamuva wrote: > > Hi Samisa, > > > > This is the inconsistency that I was talkng about in the previous mail. > > > > axiom_node_t *node = NULL, *n1 = NULL, *n2 = NULL, *n3 = NULL, *n4; > > axis2_char_t *out = NULL; > > axiom_element_t *e1, *e2 = NULL, *e3 = NULL, *e4 = NULL; > > axiom_namespace_t *nmsp = NULL; > > env = axutil_env_create_all("test.log", 1); > > if (!env) > > return NULL; > > > > nmsp = axiom_namespace_create(env, NS, "test"); > > e1 = axiom_element_create(env, NULL, "local1", nmsp, &n1); > > e2 = axiom_element_create(env, n1, "child1", nmsp, &n2); > > out = axiom_node_to_string(n1, env); > > > > /* assume following code is written in another method that we > > don't have access to the original nmsp because e1 and e2 creation > > works fine with the same namespace I would expect that e3 and e4 > > will also work*/ > > > > nmsp = axiom_namespace_create(env, NS, "test"); > > e3 = axiom_element_create(env, n1, "child2", nmsp, &n3); > > out = axiom_node_to_string(n1, env); > > /* when we debug we see that nmsp is still non-null although it > > is being freed*/ > > e4 = axiom_element_create(env, n1, "child3", nmsp, &n4); > > out = axiom_node_to_string(n1, env); > > > > The above code works until the creation of e3. I think I was little > > bit off the point in the previous mail. This happened to me while > > ago and I guess I forgot the details. Sorry for that. > > > > Regards, > > Supun.. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
