RE: Question regarding removal of a node from its parent
Manjula, I think there is something else going on here. Axiom_node_free_tree performs a detach as the first step of its processing, so doing an explicit detach before calling it should have no effect. Looking at the code in axiom_node_navigator, it appears that it intends to do a depth first search of the tree. In the context of the example, it should return in order the text node for "hello", the element node for "b", the text node for "I say", then the element node for "a". The only exception to this depth first search is the root node, as the root node as the first node returned, not the last. Rinil, looking at the code it is not obvious why this should fail, assuming that the root of the built navigator points above the initial structure you describe. I'm not sure what you meant when you wrote "broke the navigator", but my best suggestion is for you to step through the code in a debug version and see what is happening. Good luck, Bill Mitchell wtmitche...@acm.org -Original Message- From: Manjula Peiris [mailto:manj...@wso2.com] Sent: Thursday, December 18, 2008 9:16 AM To: Apache AXIS C Developers List Subject: Re: Question regarding removal of a node from its parent Rinil, Call axiom_node_detach(node, env). -Manjula. On Thu, 2008-12-18 at 14:33 +, Baxi, Rinilkumar (TCS) wrote: > Hello, > > > > I am using axiom_navigator to traverse an axiom node. Now, I > need to remove a specific node from the parent and keep the rest of > the tree navigable. For eg; > > > > Initial struct : helloI sayworld > > > > After removal of node b: I sayworld > > > > I tried using the function axiom_node_free_tree. The function did > release the node but it broke the navigator also. > > > > Could you please suggest some way in which I could remove the node and > still be able to move ahead in the tree. > > > > Thanks, > > Rinil > >
RE: Multi-threading
Patrick, thanks for your other note addressing Supun. I, too, was a little puzzled trying to understand his response, as I had not experienced any instances of crashes/failures from double frees in Axis2c (provided I avoided libxml). Thinking about Supun's comments, I concluded that this must be a difference between sync and async I/O. From your description, the implementation architecture I chose matches yours: a pool of threads performing synchronous I/O. Thus I fortuitously avoided the problem that Carl and you ran into with asynchronous calls, and that you worked around when you went to synchronous calls. Best regards, Bill Mitchell wtmitche...@acm.org -Original Message- From: Patrick van Beem [mailto:patrick.van.b...@quintiq.com] Sent: Tuesday, December 16, 2008 6:20 AM To: Apache AXIS C Developers List Subject: Re: RE : Multi-threading Hello Carl, > What Axis does well is freeing resources (once we figure out how to set > everything up right!) so I am a little confused as to where exactly the > limitations are. You say the callback system provided is not good in > terms of freeing resources, but have you tried freeing your resources > from another function which itself waits for the callback to occur? > (either error callback or success callback) I think this is the way > Axis was designed with as implied by Dimuthu: wait in a loop in your > main thread while the callbacks are outstanding, do no cleanup in the > callback itself, let that thread exit completely and after it is done, > then from your main thread detect that the callback ocurred and do the > cleanup there. Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this. Right now, the framework does not provide a safe way of freeing resources in async calls. > My reason for responding though is really to comment on this phrase: > "Threads are a rather expensive resource to use for just waiting on an > IO completion". It may be my lack of understanding, but I am pretty > sure that -- at least in the win32 tcp/ip stack -- once your thread goes > into asynchronous communication on a socket, you do not see it again > until there is some result. This means if there is a timeout your > thread is inactive for a long time. Correct. So if I've got a couple of hundred outstanding calls, they all consume precious memory. In our case, this is a lot of memory, since we have a heavy server applications with a greedy memory allocation strategy per thread (for performance) and a rather large default stacks. Of course, both can be optimized for the 'just waiting on io-completion'-threads... CPU-wise, it's no problem. > How can one thread wait on more > than one asychronous communication? I admit this would be a far better > solution, however from my understanding of winsock2 it is not possible. With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports (though a pool of threads might be a good idea if the number of sockets grows large). This is also used by the well known boost (C++) library. Mechanisms like these would be a much better implementation. But I think they don't fit well in the modular (transportation) design of axis, since they require knowledge about the lower level transportation on a higher level. > Seen this way, one thread per socket communication is maybe expensive in > resources, but it is the only way to ensure your main thread continues > to operate in a timely fashion. But prone to explode with a log of async calls. As a 'workaround' I've now my own static-sized thread pool that perform synchronous calls. If there are more async calls then threads in the pool, they're queued. Thank you for your input. -- Patrick van Beem Sr. Software engineer Quintiq
RE: Multi-threading
Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the "global" environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. Good luck, Bill Mitchell -Original Message- From: Lefrancois, Carl [mailto:carl.lefranc...@axa-canada.com] Sent: Thursday, December 11, 2008 9:56 AM To: Apache AXIS C Developers List Subject: RE : Multi-threading Hello Patrick, Manjula kindly provided a best-practice example for how to do multi-threading with Axis2/C [1] (at least on the client side) if I remember correctly, it was one environment per thread, and the stubs were per call? Well in his example it is svc_client and not stub, but if I understand correctly, those two concepts are one-to-one, meaning one stub has one svc_client. >From my point of view it seems the troubles you are encountering are based in areas where Axis does little or nothing to help the programmer. I have not seen any code to manage thread creation and resources acces in the Axis2/C project. Problems like resource deadlock on the configuration file are outside the scope of what Axis2/C has to offer. What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. For environment vs stub issues, there is no alternative but to take ownership of this problem directly and implement some synchronisation outside the scope of Axis2/C. Your code synchronises creation of threads and initialisation to avoid having deadlock problems. Maybe there is some improvement to be made to Axis here? My reason for responding though is really to comment on this phrase: "Threads are a rather expensive resource to use for just waiting on an IO completion". It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long time. How can one thread wait on more than one asychronous communication? I admit this would be a far better solution, however from my understanding of winsock2 it is not possible. Seen this way, one thread per socket communication is maybe expensive in resources, but it is the only way to ensure your main thread continues to operate in a timely fashion. Hth Carl [1] http://marc.info/?l=axis-c-user&m=118404667311058&w=2 -Message d'origine- De : Patrick van Beem [mailto:patrick.van.b...@quintiq.com] Envoyé : jeudi, décembre 11, 2008 05:46 À : axis-c-dev@ws.apache.org Objet : Multi-threading Hello, I'm experiencing serious limitations while using axis in a multi-threading environment. I know axis is not fully designed (yet?) for multi-threading, but I think some 'small' changes might make it more usable. One can't deny multi-threading. Here my 2 cents: * Callback and resources In a multi-threading environment, an asynchronous job is often responsible for freeing it's own resources (in this case, the environment, the stub and possible extra application dependent data). In the axis framework, this can't be done in the callback, since the framework will use the stub after the callback is finished. This makes it impossible for an application to free resources after a call has finished (because you never know exactly when the call (including the framework part of it) is finished. This makes the asynchronous imple
RE: Possible improvements to Axis2/C
Supun, when I read your proposal, I started to wonder how long the
memory/buffer containing the strings will persist, since as soon as the
underlying buffer is freed or reused the axiom tree using pointers to these
strings will become invalid. I am guessing that the buffer is freed or
reused when the next request is issued, and you are assuming that at that
time the tree structure from the last request has also been freed.
My particular concern is with the logic in axiom_node_detach. This is used
to transfer ownership of a subtree from the axiom tree to the caller. Among
other users of this routine, the generated adb classes use axiom_node_detach
to return to the application the subtree corresponding to WSDL data of type
Any. The application may retain ownership of these returned subtrees for
long periods, well beyond the next request.
To maintain the current API, I infer that axiom_node_detach will need to
traverse the entire subtree that is being detached, look for any strings
that are not owned, and replace them with new copies of the strings that are
owned. So, as well as the new routines you suggested like
axiom_element_create_nos, won't you need another set of routines like
axiom_element_force_ownership for each axiom structure? Axiom_node_detach
could invoke these force_ownership routines on each element of the subtree
to make sure that every unowned string is replaced.
Regards,
Bill Mitchell
From: Supun Kamburugamuva [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 12:49 AM
To: Apache AXIS C Developers List
Subject: Re: Possible improvements to Axis2/C
Hi List,
I have managed to get this thing working. The purpose of this implementation
is to avoid duplicating strings from the parser to the axiom level.
Guththila keeps a buffer of the incoming XML. Instead of duplicating XML
Strings from this buffer Guththila can give a pointer to the starting
position of the string in the buffer. We need to build Axiom by using these
pointers and Axiom shoudn't assume the ownership of these strings. This is
the brief summary of what I have done.
Axiom Model Level
Basically I have introduced a Boolean flag to virtually every structure on
Axiom as well axutil_qname_t structure. This flag indicates weather we are
allowed to free the string buffers or not. Here is an example.
struct axiom_comment
{
/** comment text */
axutil_string_t *value;
/* True if we are allowed to free string buffers */
axis2_bool_t owns_strings;
};
Then I have introduced a new create method for all the structures in om.
This method creates the structure without assuming the ownership of the
strings. Following is the new method for axiom_element_t structure.
axiom_element_create_nos(params same as normal create method)
I don't feel right about the name of the method (nos means "not owns
strings"). So I would like to here a more readable name from you guys.
This create method sets the owns_strings to FALSE and all the getter methods
and setter methods were changed to act according to the owns_strings field.
These are the only changes to the Axiom level and as you can see no API
changes. Just few additional API methods.
Stax Level
I have introduced the "owns_strings" Boolean flag to the
axiom_stax_builder_t structure. If this is FALSE, builder will build the
tree without assuming the ownership of the strings. So I have introduced a
new create method for stax builder as well.
AXIS2_EXTERN axiom_stax_builder_t *AXIS2_CALL
axiom_stax_builder_create_nos(
const axutil_env_t * env,
axiom_xml_reader_t * parser);
In all the stax builder methods the owns_strings flag is checked and
appropriate methods are called to build the om tree. For example if this
flag is FALSE the newly added axiom_element_create_nos will be called
instead of axiom_element_create_str.
Parser Level
I have introduced a new method to the axiom_xml_reader API. The method is
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_set_duplicate_strings(
axiom_xml_reader_t * parser,
const axutil_env_t * env,
axis2_bool_t is_duplicate);
This method will try to set the parser to not to duplicate strings. If the
method is unsuccessful (in the case of Libxml2) this method will return
false. The advantage of this method is that depending on the return value of
this method we can create the appropriate stax builder (one that uses
duplicated strings or one that uses strings as pointers to a buffer).
The implementation is at an experimental level. All the samples are working
but there are memory leaks in the system. Also I haven't check the
implementation with Libxml2. We need to do a performance test and see
weather this gives a good performance gain as well.
Regards,
Supun.
On Mon, Jun 2, 2008 at 6:16 AM, Supun Kamburugamuva <[EMAIL PROTECTED]>
wrote:
AFAIK yes we can do this. The only thing is we need to introduce the
axu
RE: Multi threading in Axis2/C
Hello Rinil, I see two aspects to the multi-threading question, whether Axis2C runs in a multi-threaded environment, and whether Axis2C itself takes advantage of a multi-threading. My experience has been on the client side; it seems your question may be on the server side, with which I am much less familiar. What I can tell you is that Axis2C can be used successfully in a multithreaded client. The key is that the processing is done in the context of an axutil environment structure. What I found is that I can share one axis configuration across multiple threads by creating multiple environments that share the same allocator and logger while each use their own axutil error handler. The separate error handler is needed so that each thread sees only its own errors, not errors that appear in another thread. Sharing the allocator allows the configuration to be processed only once for the client app, instead of being processed as each thread is initialized. So, in this case, Axis2C client is running in a multithreaded environment, without taking any particular advantage of multithreading itself. Perhaps someone else can shed some light your question about the message receiver. Enjoy, Bill -Original Message- From: Baxi, Rinilkumar (TCS) [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 6:19 AM To: Apache AXIS C Developers List Subject: Multi threading in Axis2/C Hello, I have been looking at the Axis2/C code. Axis configuration files indicate that Axis supports multi threading. It appears at first glance that it is the HTTP listener (in transport phase) which provides multi threading support. And the rest of Axis(Axis engine, message receiver) is single threaded. Kindly let me know whether my understanding is correct. Also I'd like to know if its feasible to introduce multi threading in the message receiver. Thanks and Regards, Rinil - 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]
RE: Novice questions regarding Axis2C client development.
Mike, I am accessing a web service where the service side is accessed through Java just fine from a C++ application using Axis2C. If the WSDL is defined, you can use the WSDL2C tool to generate C stub wrappers that represent the information from the WSDL and make the use of the Axis2C client interfaces easier. Obviously on the conversion to the SOAP messages, Axis2C takes care of converting the C data to SOAP character format on the client-side, and the Java SOAP interface code on the service side handles the conversion between SOAP and Java types. So if there is a WSDL for the service and the service is thus accessible through SOAP, you should only need to worry about the client side. When I started my development, then, I chose one of the simplest methods in my WSDL to invoke and worked out the issues accessing it, then expanded my client code to use the other interfaces. This gives you the chance to learn how to use the methods in the generated stub wrappers to access one service, then incrementally expand to implement the full application. Once you have worked through the details to make the client application find and link to the Axis2C DLLs and related libraries, and find the Axis2C repo directory on the client, accessing the services after the first becomes fairly straightforward. Good luck, Bill Mitchell From: Mike Zhao [mailto:[EMAIL PROTECTED] Sent: Friday, May 02, 2008 4:44 PM To: Apache AXIS C Developers List Subject: RE: Novice questions regarding Axis2C client development. Thank you for the concise and definite answer! Then came to the implementation. Does the server side have to do something extra, besides providing a service WSDL, for the Axis2C based client to invoke its functions? I mean has to the service side provide a particular wrapper around itself, in order for the client to interface to it? If not necessarily, then how could client talk to the service since it's implemented in Java? Any suggestions and advice will be appreciated! Mike > Date: Sat, 3 May 2008 00:00:25 +0530 > From: [EMAIL PROTECTED] > To: axis-c-dev@ws.apache.org > Subject: Re: Novice questions regarding Axis2C client development. > > Mike Zhao wrote: > > Hi There, > > > > I'm trying to use Axis2C to develop a SOAP client that would > > need interface with the Apache CXF based web services. These > > services were largely implemented in Java, though the client needs to > > be in C++. > > > > The first question I have is how feasible this could be? Or simply, > > would this be possible, and if it'd, what could be the impact to the > > performance due to the message/method conversions between two language > > implementations. > > Yes, it is possible. > > > > > Assuming this scenario would be feasible, then technically, my guess > > was I'd need to create a C/C++ wrapper/skeleton around the services, > > which would interface with/invoke the functions of interest. > > > > Yes. > > Samisa... > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > _ Windows Live SkyDrive lets you share files with faraway friends. Start sharing. <http://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh _skydrive_052008>
RE: Axiom
Varuna,
There is a processing difference in a multi-threaded environment. If you
are using an iterator, you are using a structure that is allocated and
attached to the tree. So if two threads are operating at the same point in
the same tree at the same time, they will be using the one iterator and one
thread will process one child, then the other thread might process the next
child. This is usually not what you want to do in a multi-threaded
environment.
Bill Mitchell
-Original Message-
From: Dinesh Premalal [mailto:[EMAIL PROTECTED] On Behalf Of Dinesh
Premalal
Sent: Wednesday, April 30, 2008 6:48 AM
To: axis-c-dev@ws.apache.org
Subject: Re: Axiom
Varuna,
"Varuna Jayasiri" <[EMAIL PROTECTED]> writes:
> What's the difference between children iterator and the
> axiom_node_get_next_sibling? Is there a difference in the way they are
> processed?
I couldn't recall where is used children iterator last time :), If you
look into children iterator implementation , you would see
axiom_children_iterator_next(
...
if (iterator->current_child)
{
iterator->last_child = iterator->current_child;
iterator->current_child =
axiom_node_get_next_sibling(iterator->current_child, env);
return iterator->last_child;
}
...
I would say there is no difference in a way they are processing. But
you could modification to iterator while processing where as you
couldn't do it with axiom_node_get_next_sibling function.
>
> When we navigate using get_first_child, get next sibling, etc. is the
parsing
> done when these methods are called?
I think yes.
>If so are the parsed data cached so that
> it's not parsed again if the functions are called twice?
Agree, If you going to cache those data, In order to cache them there
is a cost, in memory, processing etc.After considering those costs
there may not be a considerable gain.
thanks,
Dinesh
--
http://nethu.org
-
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]
[jira] Commented: (AXIS2C-1046) mod_axis2.dll load fails on Win XP SP2 (Japanese edition)
[ https://issues.apache.org/jira/browse/AXIS2C-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576288#action_12576288 ] Bill Mitchell commented on AXIS2C-1046: --- Exactly. A global fix will require the wchar approach. And a global fix will allow support for other character encodings in the messages, e.g., UTF-16 and byte-order-markers and all that implies. I just wanted to raise the question, whether there is something going on here such that some local solution might work. Or, alternatively, that something is going on here in the Japanese XP case that is not covered just by adding wide-char (UCS-2) support. My test environment is Windows US, where many things happen to work using UTF-8, and I'm focused on the client side, not Axis under Apache server, so I don't have a good test bed to investigate this in detail. Ikeda, to ensure that whatever fix is implemented covers your situation, you might want to investigate this in a little more detail to see what is happening at each level. Of course, as is implied in your problem description, you might already have a work around of placing the mod_axis2.dll in a path that does not use Japanese characters. > mod_axis2.dll load fails on Win XP SP2 (Japanese edition) > - > > Key: AXIS2C-1046 > URL: https://issues.apache.org/jira/browse/AXIS2C-1046 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: 1.3.0 > Environment: Win XP SP2 (Japanese edition) >Reporter: Ikeda > > Apache fails to initialize and abort in following circumstance: > - when Apache need to load mod_Axis2.dll > - and if its absolute path contains non-ascii characters (2 byte Japanese) > we confronted such thing when running Apache in Win XP Japanese -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-1046) mod_axis2.dll load fails on Win XP SP2 (Japanese edition)
[ https://issues.apache.org/jira/browse/AXIS2C-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576235#action_12576235 ] Bill Mitchell commented on AXIS2C-1046: --- Hi Senaka, I would hate for someone to read your comment too broadly, as the Axis2C passing of Unicode in a char * as UTF-8 works fine for many applications. I have done some light testing passing UTF-8 data from the application to the server through Axis2C without any problem. So it would seem in this particular situation, the problem must lie in the Apache to mod_axis2 side, or in the Axis2C interface to the OS, or both. Do you know, does Apache pass its Unicode data only in wide-char (UCS-2) format? I believe Windows XP actually records filenames in UTF-8; do the Windows file APIs, e.g., open(), support only ASCII data in a char * filenames? They might accept UTF-8 filenames. This might be an entirely different issue, if Apache passes the filename in the OEM character set, e.g, SJIS, etc., that is wide char but not Unicode. Regards, Bill > mod_axis2.dll load fails on Win XP SP2 (Japanese edition) > - > > Key: AXIS2C-1046 > URL: https://issues.apache.org/jira/browse/AXIS2C-1046 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: 1.3.0 > Environment: Win XP SP2 (Japanese edition) >Reporter: Ikeda > > Apache fails to initialize and abort in following circumstance: > - when Apache need to load mod_Axis2.dll > - and if its absolute path contains non-ascii characters (2 byte Japanese) > we confronted such thing when running Apache in Win XP Japanese -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-1040) Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
[ https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574719#action_12574719 ] Bill Mitchell commented on AXIS2C-1040: --- Agreed, Senaka, I'm easy. You're probably right that there is no other purpose for AXIS2_EXPORT except for these DLL entry points, so making it be empty in the header file in the static build works just as well as providing conditional compilation in the modules themselves. I did not verify if there were other uses when I wrote my comments above, just the uses Frank pointed out. > Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in > static build > - > > Key: AXIS2C-1040 > URL: https://issues.apache.org/jira/browse/AXIS2C-1040 > Project: Axis2-C > Issue Type: Bug > Components: util >Reporter: Frank Huebbers > > I have seen a few places where the typedef AXIS2_EXPORT is used instead of > AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels: > - axis2_msg_recv.h > - msg_recv.c > - raw_xml_in_out_msg_recv.c > - svr_callback.c > - mod_addr.c > - http_transport_sender.c > - http_receiver.c > - http_svr_thread.c > - tcp_transport_sender.c > - tcp_svr_thread.c > - tcp_receiver.c > Note that the definitions are correct in the header files. > Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote][Axis2]Axis2/C 1.3.0 Release Artifacts
In addition to the release Windows binary (libxml2), I built the Windows source using libcurl and guththila, and it worked fine. Here is my +1. Thanks, Bill Mitchell Dinesh Premalal wrote: > Hi Devs, > > I have packaged and uploaded the Apache Axis2/C 1.3.0 release > artifacts at [1]. The key used to sign the release artifacts can be > found at [2]. > > Please test, review and vote on the release artifacts for Apache > Axis2/C 1.3.0 release. > > I have tested and reviewed them and here is my vote: +1 > > Thanks, > Dinesh > > 1. http://people.apache.org/~dinesh/release/1.3.0/ > <http://people.apache.org/%7Edinesh/release/1.3.0/> > 2. http://www.apache.org/dist/ws/axis2/c/KEYS > > > -- > http://nethu.org/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-1040) Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
[ https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574045#action_12574045 ] Bill Mitchell commented on AXIS2C-1040: --- Looking at the exports from the Windows DLLs, I suspect that the AXIS2_EXPORT declaration is required for the dynamic link. The likely fix is to ensure that the AXIS2_EXPORT declaration is present only in the non-AXIS2_STATIC_DEPLOY case by including it within the #ifndef. Such ifndef declarations are already present in http_transport_sender.c; the AXIS2_EXPORT there just lies outside the ifndef. > Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in > static build > - > > Key: AXIS2C-1040 > URL: https://issues.apache.org/jira/browse/AXIS2C-1040 > Project: Axis2-C > Issue Type: Bug > Components: util >Reporter: Frank Huebbers > > I have seen a few places where the typedef AXIS2_EXPORT is used instead of > AXIS2_EXTERN. Doing a simple search, I have seen this in the following fiels: > - axis2_msg_recv.h > - msg_recv.c > - raw_xml_in_out_msg_recv.c > - svr_callback.c > - mod_addr.c > - http_transport_sender.c > - http_receiver.c > - http_svr_thread.c > - tcp_transport_sender.c > - tcp_svr_thread.c > - tcp_receiver.c > Note that the definitions are correct in the header files. > Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-1015) In axutil_uri, a reference is returned, where a duplicated string should be.
[ https://issues.apache.org/jira/browse/AXIS2C-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573357#action_12573357 ] Bill Mitchell commented on AXIS2C-1015: --- Although I've not researched exactly how the axutil_uri_get_xxx accessors are used, it appears that generally throughout Axis2C the _get_ accessors return axis2_char_t * or similar references without a const declaration, and with no intention of allowing the caller to modify the indicated string. Consider, for example, axiom_namespace_get_prefix in axiom_namespace.h. Changing every such interface to return a duplicate will introduce a lot of overhead and will mean that the callers must take ownership and free the associated memory. It would be better to perform a general overhaul of the interfaces to add const to the declarations, although such a change, too, will naturally propagate throughout the callers' code as well. > In axutil_uri, a reference is returned, where a duplicated string should be. > > > Key: AXIS2C-1015 > URL: https://issues.apache.org/jira/browse/AXIS2C-1015 > Project: Axis2-C > Issue Type: Bug > Components: util >Affects Versions: 1.3.0 >Reporter: Senaka Fernando >Assignee: Senaka Fernando > > In axutil_uri, a reference is returned, where a duplicated string should be. > This is because we return axis2_char_t * rather than const axis2_char_t *. > However, a user is expected to be able modify what is returned, according to > current api, and thus we must return a cloned copy of the actual string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Vote][Axis2]Axis2/C 1.3.0 Release Artifacts
Dinesh, I noticed when I unzipped the 1.3 build that there was no guththila.dll, which implies to me that it was still built with libxml2 as the parser. As there are no open guththila Jira reports, I don’t think there is any reason guththila can’t be the default parser. Even though this was raised as a suggestion a month ago, my guess is that no one remembered, after all the issues were fixed, to go ahead and change over the default. It’s probably too late at this point to switch, but I wanted to bring it to your attention. It may be that during the 1.3 development cycle, guththila actually received more use and testing than did the libxml interface. Bill Mitchell From: Dinesh Premalal [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 27, 2008 9:47 AM To: Apache AXIS C Developers List Subject: [Vote][Axis2]Axis2/C 1.3.0 Release Artifacts Hi Devs, I have packaged and uploaded the Apache Axis2/C 1.3.0 release artifacts at [1]. The key used to sign the release artifacts can be found at [2]. Please test, review and vote on the release artifacts for Apache Axis2/C 1.3.0 release. I have tested and reviewed them and here is my vote: +1 Thanks, Dinesh 1. http://people.apache.org/~dinesh/release/1.3.0/ <http://people.apache.org/%7Edinesh/release/1.3.0/> 2. http://www.apache.org/dist/ws/axis2/c/KEYS -- http://nethu.org/
[jira] Resolved: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-675. -- Resolution: Fixed Fix Version/s: 1.3.0 > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Assignee: Bill Mitchell > Fix For: 1.3.0 > > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (AXIS2C-675) Detach node does not handle namespaces
Sanjaya, as Dinesh included the AXIS2C-675 fix into the head, should I include the new routine to perform a copy of an axiom subtree into the axiomfix branch as it stands today? Or would it be better to recreate this branch starting at a later revision that already includes the 675 fix, to make the merge process later easier? Thanks, Bill Mitchell -Original Message- From: Dinesh Premalal (JIRA) [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 3:34 AM To: [EMAIL PROTECTED] Subject: [jira] Commented: (AXIS2C-675) Detach node does not handle namespaces [ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571325#action_12571325 ] Dinesh Premalal commented on AXIS2C-675: Bill, I applied the patch and tested in the svn head, for me It didn't give any problem. Ill commit it to the svn head. > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon >Assignee: Bill Mitchell > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -Original Message- From: Sanjaya Ratnaweera [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 10:37 AM To: Apache AXIS C Developers List Subject: Re: Issue in using 'detach' for cloning Hi Bill, I have applied the updated patch to the branch. So I think we can have the branch ready until we come to a decision. thanks ~sanjaya 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. 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issue in using 'detach' for cloning
Thanks for the vote of confidence, Senaka. My test platform lets me verify that the change fixes the problem situations without having any effect on detach operations the generated adb classes. I am able to modify the SOAP response messages from the server for testing to insert prefixes on attributes and subordinate elements and see that valid references are preserved. Being valid xml, the action of re-declaring the namespaces at the level of the detached node should have no adverse impact on Rampart/C nor Sandesha2/C. And, once integrated and released, anyone can take advantage of free performing an implied detach to make the free process more efficient. Regards, Bill -Original Message- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 12:38 PM To: axis-c-dev@ws.apache.org Subject: RE: Issue in using 'detach' for cloning > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] >>> 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. >
RE: Issue in using 'detach' for cloning
Samisa, it looks to me as if the branch Sanjaya created so far has only my changes to AXIS2C-675. I think I misread this email the first time to say that you had already written the changes to implement a clone method. Were you intending that the source for axiom_node_clone that serialized/deserialized would be in om_node.c? If so, I'm thinking that's where my draft of an axiom_node_copy belongs, too. Second question, I don't see a Jira work item open about building a clone routine or an alternative copy routine. It does appear that we could reopen AXIS2C-677 and track the activity there. What do you think? Thanks, Bill -Original Message- From: Sanjaya Ratnaweera [mailto:[EMAIL PROTECTED] Sent: Monday, February 18, 2008 9:39 AM To: Apache AXIS C Developers List Subject: Re: Issue in using 'detach' for cloning 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... > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issue in using 'detach' for cloning
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. Regards, Bill -Original Message- From: Senaka Fernando [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] >> 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: [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] > > - 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]
RE: Issue in using 'detach' for cloning
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. 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt While working on the routine to copy a node tree, I found it needed the same worker routines as did axiom_node_detach to manage namespaces declared in a parent of the subtree being copied/detached. As well, looking at these routines they knew a lot more about the internals of elements than they had to do with the node structure. So, this third version moves the worker routines into om_element.c where they fit a little better. > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Assignee: Bill Mitchell > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Assignee: Bill Mitchell > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570667#action_12570667 ] wtmitchell3 edited comment on AXIS2C-675 at 2/20/08 4:29 AM: --- I've updated the attached diff to include two additional changes. (1) Detach is now included as one of the actions of axiom_node_free, when the node still has a parent. All the appropriate points in Axis have been changed to take advantage of this. This allows the free process to perform an internal detach that avoids preserving the integrity of namespace references. (2) When a node is detached, it determines all the namespaces in its parents that may be inscope for it or its children. The new action is then to scan the subtree to determine which of these namespaces are actually referenced in the subtree, and to redeclare only the namespaces that are actually referenced. Senaka, I think that (2) resolves most of your concern about increasing the size of the payloads with unused namespace declarations, at the cost of scanning the subtree during detach. I do have a clever idea of something that could be done during attach, to further address your payload size concern without modifying all the namespace reference values. We could promote the declared namespaces up the tree to a higher parent, detecting if the namespace has already been declared at the higher node. This would eliminate multiple declarations when multiple detached subtrees are attached to a new tree. I'm reluctant to implement this, though, as it would make no difference in the case with which I'm familiar of the generated adb stubs. The adb classes serialize the pieces of the request message directly, without first collecting them into one tree via attach, so repetitive namespace declarations in multiple passed request objects would not be removed. This diff is relative to the head. I will be working on the discussed axiom_node_copy method separately so it can be on a branch. was (Author: wtmitchell3): I've updated the attached diff to include two additional changes. (1) Detach is now included as one of the actions of axiom_node_free, when the node still has a parent. All the appropriate points in Axis have been changed to take advantage of this. This allows the free process to perform an internal detach that avoids preserving the integrity of namespace references. (2) When a node is detached, it determines all the namespaces in its parents that may be inscope for it or its children. The new action is then to scan the subtree to determine which of these namespaces are actually referenced in the subtree, and to redeclare only the namespaces that are actually referenced. Senaka, I think that (2) resolves most of your concern about increasing the size of the payloads with unused namespace declarations, at the cost of scanning the subtree during detach. I do have a clever idea of something that could be done during attach, to further address your payload size concern without modifying all the namespace reference values. We could promote the declared namespaces up the tree to a higher parent, detecting if the namespace has already been declared at the higher node. This would eliminate multiple declarations when multiple detached subtrees are attached to a new tree. I'm reluctant to implement this, though, as it would make no difference in the case with which I'm familiar of the generated adb stubs. The adb classes serialize the pieces of the request message directly, without first collecting them into one tree via attach, so repetitive namespace declarations in multiple passed request objects would not be removed. > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon >Assignee: Bill Mitchell > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt I've updated the attached diff to include two additional changes. (1) Detach is now included as one of the actions of axiom_node_free, when the node still has a parent. All the appropriate points in Axis have been changed to take advantage of this. This allows the free process to perform an internal detach that avoids preserving the integrity of namespace references. (2) When a node is detached, it determines all the namespaces in its parents that may be inscope for it or its children. The new action is then to scan the subtree to determine which of these namespaces are actually referenced in the subtree, and to redeclare only the namespaces that are actually referenced. Senaka, I think that (2) resolves most of your concern about increasing the size of the payloads with unused namespace declarations, at the cost of scanning the subtree during detach. I do have a clever idea of something that could be done during attach, to further address your payload size concern without modifying all the namespace reference values. We could promote the declared namespaces up the tree to a higher parent, detecting if the namespace has already been declared at the higher node. This would eliminate multiple declarations when multiple detached subtrees are attached to a new tree. I'm reluctant to implement this, though, as it would make no difference in the case with which I'm familiar of the generated adb stubs. The adb classes serialize the pieces of the request message directly, without first collecting them into one tree via attach, so repetitive namespace declarations in multiple passed request objects would not be removed. > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon >Assignee: Bill Mitchell > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reassigned AXIS2C-675: Assignee: Bill Mitchell > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Assignee: Bill Mitchell > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Assignee: Bill Mitchell > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: (was: diff.txt) > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-675: - Attachment: diff.txt The attached diff.txt implements a change to attach all the namespaces in scope on an element node being detached to the element, so that the detached node and all its children will still have valid namespace references even if the former parent tree is freed. Beyond the obvious change to detach to preserve the namespace, it required cleaning up several places in om_element that would allow an attribute to be attached without the namespace structure it pointed to being declared at the element or one of its parents. The former code seemed to accept that the namespace uri or prefix was declared somewhere, without requiring that the very same structure be used. Testing also revealed another anomaly. Now that guththila behaves like libxml and parses xml:id attributes, with this change the xml: namespace would be preserved in the detached node. When that structure was subsequently serialized and passed to a remote system not using Axis, in particular a system using the Microsoft xml parser, this unnecessary but allowed xml namespace declaration is diagnosed as an error. So we should just not emit it on output. > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > Attachments: diff.txt > > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2C-675) Detach node does not handle namespaces
[ https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-675: -- This problem has been encountered again recently, and it appears to me there is a real issue in axiom_node_detach and how it is used. Consider the case of a SOAP response message in which the server declared the namespaces at one of the outer elements. Where a wsdl declares an element of type any, not knowing the underlying structure, the generated adb classes detach the node and its subtree and makes the tree available to the client app. The client app may choose to retain the response structure and the returned object tree for later use. Yet the upper levels of the om will be discarded when the SOAP response message is discarded upon the next request through the service client. And, thus, Axis will free the namespaces underneath the adb objects. It hardly seems fair to place the responsibility on the creator of the tree not to release the namespaces underneath the detached node, when the tree is created as the SOAP message is parsed, and the location of the xml namespace declaration in the message is determined by the other side of the exchange. An alternative fix is to re-declare the namespaces on the node being detached, to ensure that it and its children remain valid regardless of what happens to its former parent tree. Re-declaring the namespaces will cause the ref counts in the namespaces to be incremented, and thus the namespace structures will be retained until both the former parent tree and the detached node tree are released. > Detach node does not handle namespaces > -- > > Key: AXIS2C-675 > URL: https://issues.apache.org/jira/browse/AXIS2C-675 > Project: Axis2-C > Issue Type: Bug > Components: xml/om >Reporter: Jamie Lyon > > When detaching a node from a parent, if the current node or any of it's > children have any namespaces declared in it's parent or above, when the node > is detached, and the parent freed, any namespace references are lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-987) Generated adb stubs do not support attributes with namespaces
Generated adb stubs do not support attributes with namespaces
-
Key: AXIS2C-987
URL: https://issues.apache.org/jira/browse/AXIS2C-987
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: 1.2.0
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
For the attributes defined in the wsdl, the generated stub classes require that
the namespace prefix be omitted from the attribute. If a prefix is attached to
the attribute, the generated stub fails to find the attribute.
For example, the following is the code that looks for a "handle" attribute:
parent_attri = NULL;
attrib_text = NULL;
if(attribute_hash)
{
axutil_hash_index_t *hi;
void *val;
const void *key;
for (hi = axutil_hash_first(attribute_hash, env); hi; hi
= axutil_hash_next(env, hi))
{
axutil_hash_this(hi, &key, NULL, &val);
if(!strcmp((axis2_char_t*)key, "handle"))
{
parent_attri = (axiom_attribute_t*)val;
break;
}
}
}
if(parent_attri)
{
attrib_text = axiom_attribute_get_value(parent_attri, env);
}
else
{
/* this is hoping that attribute is stored in "handle",
this happnes when name is in default namespace */
attrib_text =
axiom_element_get_attribute_value_by_name(parent_element, env, "handle");
}
The strcmp compares the attribute key against the string "handle", but the
attribute key is the qname string from the attribute.
Obviously the robust fix is to ensure the attribute localname matches, and that
the namespace uri matches if present.
The quick fix is to replace the strcmp with something like:
if(!strcmp(axiom_attribute_get_localname((axiom_attribute_t *)val, env),
"handle"))
I suspect this quick fix is not the longterm fix, as it accepts an attribute
with a different uri than that expected. It appears to me that the non-uri
case is handled later in the code by the
axiom_element_get_attribute_value_by_name call. The hash search loop was
probably intended to compare against the attribute qname, but the qname logic
was may have been removed temporarily or not fully implemented to solve other
issues with the default namespace or multiple namespaces in the wsdl.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568414#action_12568414
]
Bill Mitchell commented on AXIS2C-791:
--
Senaka, following your suggestion, I restored the AXIS2_ERROR_SET calls in svn
rev 627226.
> On in-out message flow that fails with no response, no error code or
> misleading error code is returned, expected error number 3.
> --
>
> Key: AXIS2C-791
> URL: https://issues.apache.org/jira/browse/AXIS2C-791
> Project: Axis2-C
> Issue Type: Bug
> Components: core/clientapi
>Affects Versions: 1.1.0
> Environment: Windows XP, Visual Studio 2005
>Reporter: Bill Mitchell
>Assignee: Bill Mitchell
>Priority: Minor
> Fix For: 1.3.0
>
> Attachments: diff.txt
>
>
> If a blocking I/O is requested for an in-out message exchange and no response
> is received, axis2_svc_client_send_receive et.al. return a zero response
> pointer. But one would expect the errno variable to contain some value
> indicating the error.
> In op_client.c in axis2_op_client_two_way_send() there is code at the very
> end, when there is no response envelope, to ensure that an error code is
> returned:
> if (AXIS2_ERROR_GET_STATUS_CODE(env->error) != AXIS2_SUCCESS)
> {
> AXIS2_ERROR_SET(env->error,
>
> AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
> AXIS2_FAILURE);
> if (engine)
> {
> axis2_engine_free(engine, env);
> engine = NULL;
> }
> axis2_msg_ctx_free(response, env);
> return NULL;
> }
> As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the
> intent is to return error number 3 when no other error has been diagnosed.
> Unfortunately, even after this fix, in the nightly build of 11/27/07, there
> is a new bug that causes error number 3 to be replaced with an uninformative
> error 2, invalid null parameter. In svc_client, when the empty response is
> returned, axis2_op_client_add_msg_ctx() is called with an intentional null
> value clear the ctx.
> In the post 1.1 source, parameter validation has been added to
> axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_op_client_add_msg_ctx(
> axis2_op_client_t * op_client,
> const axutil_env_t * env,
> axis2_msg_ctx_t * mc)
> {
> axis2_msg_ctx_t *out_msg_ctx = NULL,
> *in_msg_ctx = NULL;
> axis2_msg_ctx_t **msg_ctx_map = NULL;
> AXIS2_PARAM_CHECK (env->error, op_client, AXIS2_FAILURE);
> AXIS2_PARAM_CHECK (env->error, mc, AXIS2_FAILURE);
> The second AXIS2_PARAM_CHECK should be removed.
> After making both these changes in the development shapshot, when the client
> receives no response, for example if the URL points to a non-running server,
> the client correctly receives error 3, Blocking invocation expects response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568125#action_12568125 ] Bill Mitchell commented on AXIS2C-963: -- In rev 620807 I incorporated a change to resolve your concern, Senaka. On the original, more global issue of preserving the entire document for formatting and similar purposes, axiom discards XML comments before the root element. I don't know if preserving this comment is important to anyone. > Guththila neglects spacing and formatting between nodes whereas libxml2 > preserves it. > - > > Key: AXIS2C-963 > URL: https://issues.apache.org/jira/browse/AXIS2C-963 > Project: Axis2-C > Issue Type: Bug > Components: guththila, xml/parser >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila neglects spacing and formatting between nodes. This behavior > contradicts to that of libxml2. Thus, If I open a file then deserialize it > and build our OM Model, then print it to the terminal, I have lost the > formatting in the file. This is because the parser simply filters out the > whitespace. This behavior would make our parsing inconsistent. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568079#action_12568079 ] Bill Mitchell commented on AXIS2C-963: -- Senaka, it's a good question whether a better fix is available. I considered whether to implement a change down in axiom_stax_builder_create_om_text(), but it doesn't know whether the text is whitespace or not. And I like the fact that non whitespace text before the root element will be diagnosed as an error. To address your concern, one could replicate the test against lastnode in axiom_stax_builder_next_with_token(), before it calls axiom_stax_builder_create_om_text(). Looking at the code again, I actually like that fix better than the one I put in, as it would preserve the ability to detect other errors, and would prevent the error being posted to the environment and then ignored. > Guththila neglects spacing and formatting between nodes whereas libxml2 > preserves it. > - > > Key: AXIS2C-963 > URL: https://issues.apache.org/jira/browse/AXIS2C-963 > Project: Axis2-C > Issue Type: Bug > Components: guththila, xml/parser >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila neglects spacing and formatting between nodes. This behavior > contradicts to that of libxml2. Thus, If I open a file then deserialize it > and build our OM Model, then print it to the terminal, I have lost the > formatting in the file. This is because the parser simply filters out the > whitespace. This behavior would make our parsing inconsistent. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-963. -- Resolution: Fixed I modified om_stax_builder.c in rev 620703 to tolerate no text node being created when white space text is encountered before the root element. > Guththila neglects spacing and formatting between nodes whereas libxml2 > preserves it. > - > > Key: AXIS2C-963 > URL: https://issues.apache.org/jira/browse/AXIS2C-963 > Project: Axis2-C > Issue Type: Bug > Components: guththila, xml/parser >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila neglects spacing and formatting between nodes. This behavior > contradicts to that of libxml2. Thus, If I open a file then deserialize it > and build our OM Model, then print it to the terminal, I have lost the > formatting in the file. This is because the parser simply filters out the > whitespace. This behavior would make our parsing inconsistent. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2C-963) Guththila neglects spacing and formatting between nodes whereas libxml2 preserves it.
[ https://issues.apache.org/jira/browse/AXIS2C-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-963: -- This change has broken incoming SOAP messages that begin with an xml declaration. What is happening is that guththila interprets the CR-LF after the declaration as GUTHTHILA_SPACE (AXIOM_XML_READER_SPACE) to be returned. But axiom_stax_builder_next_with_token diagnoses an error and returns -1 when the space token cannot be attached as text to the last node (there is no last node) by axiom_stax_builder_create_om_text(). The end result is that the client sees an error number 187, SOAP message does not contain a SOAP envelope element. > Guththila neglects spacing and formatting between nodes whereas libxml2 > preserves it. > - > > Key: AXIS2C-963 > URL: https://issues.apache.org/jira/browse/AXIS2C-963 > Project: Axis2-C > Issue Type: Bug > Components: guththila, xml/parser >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila neglects spacing and formatting between nodes. This behavior > contradicts to that of libxml2. Thus, If I open a file then deserialize it > and build our OM Model, then print it to the terminal, I have lost the > formatting in the file. This is because the parser simply filters out the > whitespace. This behavior would make our parsing inconsistent. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-966) Guththila has no support for XML declarations
[ https://issues.apache.org/jira/browse/AXIS2C-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567627#action_12567627 ] Bill Mitchell commented on AXIS2C-966: -- Senaka, here's another question, while we are both thinking about this. I noticed in axis2_libcurl that it causes the xml declaration to be built, then it determines the text encoding to be inserted in the http content-type header. And I was wondering why this would not be done in the other order? As the http content-type character encoding may be configurable, it would make sense, absent other information, to identify the same character encoding in the http content-type header and in the xml declaration. > Guththila has no support for XML declarations > - > > Key: AXIS2C-966 > URL: https://issues.apache.org/jira/browse/AXIS2C-966 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: 1.3.0 >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila has no support for XML declarations. Bill, pointed this out in an > e-mail sent to the AXIS2C-dev list. It is required that Guththila understands > the XML declaration elements and simply do not treat it as an error. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-966) Guththila has no support for XML declarations
[ https://issues.apache.org/jira/browse/AXIS2C-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567620#action_12567620 ] Bill Mitchell commented on AXIS2C-966: -- Actually, Senaka, I think that guththila could handle other single byte encodings today. Obviously multibyte encodings like UTF-16 are another story. But on the single byte latin encodings, 8859-x, I think all the special characters that are significant to XML are at the same code points. When I was looking at verifying this on incoming messages, the stumbling block I found was that the character encoding from the ?xml declaration is passed up only one layer and then lost, the client app doesn't seem to have a way to learn which encoding was used. Except for that, I think guththila and the rest of Axis2c is neutral for all single byte encodings. Regards, Bill > Guththila has no support for XML declarations > - > > Key: AXIS2C-966 > URL: https://issues.apache.org/jira/browse/AXIS2C-966 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: 1.3.0 >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila has no support for XML declarations. Bill, pointed this out in an > e-mail sent to the AXIS2C-dev list. It is required that Guththila understands > the XML declaration elements and simply do not treat it as an error. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-959) Guththila parser can't handle comments.
[ https://issues.apache.org/jira/browse/AXIS2C-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567615#action_12567615 ] Bill Mitchell commented on AXIS2C-959: -- Senaka, I thought your changes looked right, but when I stepped through them on a SOAP message containing a comment, I found the calculated length of the comment was one character too short, so the comment value was getting truncated. It seems the token open/token close logic in guththila expects that the character following the token has already been scanned, here the leading hyphen. I checked in a fix to adjust the next pointer back by 2 instead of 3, in rev 620476. Regards, Bill > Guththila parser can't handle comments. > --- > > Key: AXIS2C-959 > URL: https://issues.apache.org/jira/browse/AXIS2C-959 > Project: Axis2-C > Issue Type: Bug > Components: guththila > Environment: Windows XP SP2, libcurl >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > Attachments: diff.txt > > > It seems that Guththila can't properly print comments appreaing in XML. It > simply adds an additional '-->' at the end unlike it's counterpart libxml2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
[
https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-936:
-
Attachment: TemplateSource.diff
Looking at the TemplateSource.xsl file, I think my suggested placement for this
new code is not quite the right place. It think it's adequate to do this only
when deserializing the entire adb_object, so it is easier to place in the xsl
where the adb object deserializing is invoked.
See the attached TemplateSource.diff for a better suggested fix. If the test
for node complete is done immediately after storing the element pointer from
deserialization, it can fit into the normal error flow of testing the status,
freeing the qname, and returning the failure, without risking a memory leak
from building the node and not storing it.
As before, I've generated this fix by inspection of the .xsl file, but I've not
yet created the Java build environment to test the modified .xsl. I have
tested hand modified versions of the generated stubs to verify that they
diagnose the error when the message is incomplete.
> On incomplete response message, the client receives response data for the
> elements up to the error, but no indication of the error
> --
>
> Key: AXIS2C-936
> URL: https://issues.apache.org/jira/browse/AXIS2C-936
> Project: Axis2-C
> Issue Type: Bug
> Components: code generation
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml or guththila,
> libcurl
>Reporter: Bill Mitchell
> Fix For: 1.3.0
>
> Attachments: TemplateSource.diff
>
>
> If the SOAP response message to the client is incomplete, i.e., there is an
> EOF indication in the middle of the message, the client receives an object
> containing the elements that could be deserialized from the message, with no
> indication that the message is incomplete. Clearly, the impact is that the
> client may act on the partial message, with no indication anywhere that data
> was lost.
> I considered whether this could be fixed in svc_client.c. Although it
> appears with the debugger that the message is usually complete when at the
> end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an
> accident of the fact that the lower level code looks for a soap fault in the
> soap body, and a SOAP 1.1 response does not have a fault in the body so the
> entire body is scanned first looking for the fault. I believe the intent is
> that the response be returned without scanning all of the tokens in the body.
> So it must be the responsibility of the generated stubs to check that all
> the data is processed when deserializing the elements.
> At the end of the deserialize method for the response message, there is code
> like the following:
> if(AXIS2_FAILURE == status)
> {
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value
> for getExemplarResponse ");
> if(element_qname)
> {
> axutil_qname_free(element_qname, env);
> }
> return AXIS2_FAILURE;
> }
> }
> else if(!dont_care_minoccurs)
> {
> if(element_qname)
> {
> axutil_qname_free(element_qname, env);
> }
> /* this is not a nillable element*/
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0
> element getExemplarResponse missing");
> return AXIS2_FAILURE;
> }
> My suggestion is that an additional test for node complete be added similar
> to this:
> if(AXIS2_FAILURE == status)
> {
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value
> for getExemplarResponse ");
> ...
> }
> if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
> {
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire
> element getExemplarResponse ");
> if(element_qname)
> {
> axutil_qname_free(element_qname, env);
> }
> return AXIS2_FAILURE;
> }
> }
> else if(!dont_care_minoccurs)
> ...
> It would probably be reasonable and safe to do this as part of all the
> generated deserialize routines. But in testing it appears sufficient to do
> this in the outermost response element routine, as this assures an error is
> returned to the client if the response message is incomplete.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-966) Guththila has no support for XML declarations
[ https://issues.apache.org/jira/browse/AXIS2C-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567513#action_12567513 ] Bill Mitchell commented on AXIS2C-966: -- Senaka, you fixed all the issues I observed at the upper layers. And I have verified that the request message sent via libcurl now contains a ?xml declaration. But the fix works in part by accident. guththila_xml_writer_wrapper_write_start_document_with_version_encoding() now receives a valid encoding and version, so it does not fail the parm checks. But it calls guththila_write_start_document() which accepts no parameters and always generates a ?xml declaration specifying version 1.0 and UTF-8, hardcoded in the string GUTHTHILA_WRITER_SD_DECLARATION. guththila_write_start_document() has no access to the values passed into guththila_xml_writer_wrapper. So if anyone configured the document to specify a different char set encoding, the ?xml declaration would indicate UTF-8 instead of the specified encoding. I'm not sure if this should be tracked as a separate issue, or as part of the same issue. My first inclination would be to reopen it, except that what is there is sufficient, I think, to match the claimed capabilities of 1.3. I don't know that there is yet any functionality in the upper levels to let the client or server app get to the om_output structure and set the char-set encoding. > Guththila has no support for XML declarations > - > > Key: AXIS2C-966 > URL: https://issues.apache.org/jira/browse/AXIS2C-966 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: 1.3.0 >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > Guththila has no support for XML declarations. Bill, pointed this out in an > e-mail sent to the AXIS2C-dev list. It is required that Guththila understands > the XML declaration elements and simply do not treat it as an error. > Regards, > Senaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-573) Fix warnings on windows
[ https://issues.apache.org/jira/browse/AXIS2C-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567252#action_12567252 ] Bill Mitchell commented on AXIS2C-573: -- I glad to see you are picking these up, Senaka. After changing the Windows makefile to /W3 to enable warnings, I was beginning to get irritated by these, too. Obviously a lot are just AXIS2_PARAM_CHECK calls that return the wrong type, e.g., AXIS2_FAILURE, in a method that is supposed to return a pointer. When I saw the signed/unsigned warnings, though, these set off bells and whistles for me. I've not looked at these in particular, but in other projects on which I have worked, the signed/unsigned warnings are usually real coding errors as the C promotion rules for signed/unsigned do not yield the comparison that a human reader expects. Thanks. > Fix warnings on windows > > > Key: AXIS2C-573 > URL: https://issues.apache.org/jira/browse/AXIS2C-573 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) > Environment: Windows >Reporter: Nandika Jayawardana >Assignee: Senaka Fernando > Fix For: 1.3.0 > > > When building axis2c source on windows, there are large number of warnings. > These warnings should be fixed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[
https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567024#action_12567024
]
Bill Mitchell commented on AXIS2C-884:
--
You're very welcome.
By the way, to implement a call to initialize libxml in my main thread, I did
not have to include all the libxml includes which caused some conflicts with
other xml related includes I had. Instead I excerpted just the fragment of the
header file for initialization and encapsulated it under an ifdef in my app:
// If libxml2 is used, instead of guththila, then we need to explicitly
initialize outside of Axis2c
#if AXIS_LIBXML_INIT_IN_MAIN_THREAD
// Define libxml entry points directly, to avoid conflicts with Xerces
#ifdef __cplusplus
extern "C" {
#endif
#include
XMLPUBFUN void XMLCALL
xmlInitParser(void);
XMLPUBFUN void XMLCALL
xmlCleanupParser(void);
#ifdef __cplusplus
}
#endif
#endif
Then I added a call to xmlInitParser() in my main thread, again under ifdef,
and worked around the problem. I may have had another issue to make sure that
libxml2 and its friends are built with the VS debug C runtime included in the
manifest, but I had already solved that issue in order to debug libxml2.
The other, simpler workaround is to rebuild Axis to use the guththila parser.
I only went back to libxml2 as I was encountering guththila problems that I
thought would take some time to resolve. All the ones I encountered in my app
have been fixed in 1.3 and it works fine for me. There are a couple of other
minor ones that are preventing the guththila parser becoming the default parser
today. I think the general direction is to move to guththila as soon as
practicable. For your app, like mine, it may be there already.
> Seg fault in libxml when svc client torn down in a multithreaded client
> ---
>
> Key: AXIS2C-884
> URL: https://issues.apache.org/jira/browse/AXIS2C-884
> Project: Axis2-C
> Issue Type: Bug
> Components: core/deployment
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml
> 2.6.30, libcurl
>Reporter: Bill Mitchell
> Attachments: axis2.trace, desc_builder_diff.txt
>
>
> In a multithreaded application, if the stub/svc client is freed in a thread
> different from that used when the svc client was built, libxml crashes. The
> trace below shows the information available from a release build with debug
> information embedded.
> I have verified this is not an effect of combining debug and release C
> runtimes, or different versions of the C runtime. Rebuilding all the libxml
> related dlls with the same runtime as is used for Axis and the client app
> does not solve the problem.
> Interestingly, rebuilding libxml with threads disabled does make the crash go
> away. But the default build of libxml commonly available has native threads
> enabled, and building without thread support may make the library not thread
> safe.
> By adding debug trace statements in the axis2.trace file, I have verified
> that the xml_reader being torn down when the crash happens is the one used to
> read the axis2.xml file when the configuration was first read. (axis2.trace
> file attached.)
> Looking at the code in libxml, it appears that libxml decides to close the
> reader using an internal close routine intended for closing compressed
> channels through zlib. Apparently the C runtime library returns a -1 EOF
> status when closing a file opened for read. The close routine, gzio.c in
> zlib, treats this as an error, and when libxml attempts to report the error
> and determines that it is in a different thread, things really go downhill
> fast. I have not isolated why the EnterCriticalSection call crashes in the
> system, but it does.
> One way to avoid the problem would be to guarantee that the stub/svc client
> is freed in the same thread as created it. In my multithreaded client
> application, though, I work hard to share the stub across threads
> deliberately to reduce the number of distinct service clients and the
> associated demand on the server.
> Windows call traceback at time of crash:
> ntdll.dll!7c918fea()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> msvcr80.dll!78134d09()
> ntdll.dll!7c910e91()
> ntdll.dll!7c9106eb()
> msvcr80.dll!78134d83()
> ntdll.dll!7c90104b()
> > libxml2.dll!xmlGetGlobalState() Line 570 C
> libxml2.dll!__xml
[jira] Updated: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[ https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-791: - Attachment: diff.txt Senaka, I worried some about the changes to axis2_op_client_add_msg_ctx. But when I saw that the code already treaterlater on the case of the incoming message_ctx value being zero, I inferred that the author intending zero to be a normal case. It does not surprise me that allowing it to go through this path again uncovered the absence of a guard on the op_ctx pointer in the client being zero, and that this would show up on some path not exercised in the SOAP flow I tested. When I looked at your changes in axis2_op_client_two_way_send, I worried that they defeated the entire purpose of my initial issue. Artificially generating a 75 error might camoflage the error reported at the lower layer. Albeit in my testing the lower layer reported an error 74, almost the same error. But in fact your change here had no effect on the test, as the env error status_code value is false at this point, and gets clobbered to be true at the AXIS2_PARM_CHECK call at the beginning of axis2_op_client_add_msg_ctx. So your change here does no harm, and may remedy some problem, but it does not remedy the problem behavior you saw. I observed this same behavior myself, that lower level routines would post an error number, but that the status code would frequently be changed back to success on the way out. So I inferred that the convention was the caller should not trust the status code, but rather if a null pointer is returned for the response message, the caller should recognize the presence of an error and grab the error number. You suggest that the env status code should always indicate whether an interesting error number is present. That's a perfectly good convention as well, it is clear and understandable, but it means that all the routines on the exit paths from the lower levels back out must not modify the status code when an error is already present, else they will mask the real error -- exactly the problematic behavior I reported. Unfortunately, the standard macros AXIS2_PARAM_CHECK and AXIS2_FUNC_PARAM_CHECK do just that. They report an error if the parameter is null, but they also change the status to success when no error is detected. As a brute force solution to the problematic behavior I reported, I have gone through all the offending routines on the error path from two-way send and changed these to avoid the AXIS2_PARAM_CHECK, to do their own testing inline, and fail appropriately without modifying the env status code when the incoming parameter is valid. (See the attached diff for the affected routines.) At best, this is a fragile solution, as it will be easy for someone to inadvertently introduce new instances of AXIS2_PARAM_CHECK in these or other routines that happen to be used on the error exit path. My suggestion, for discussion, is that AXIS2_PARAM_CHECK and AXIS2_FUNC_PARAM_CHECK routines should never set the env status code to success. Rather, the env status code should be set to success only at the initial outer entry points to the main component routines, and wherever a reported error is ignored and processing continues. But implementing this suggestion requires someone spend a fair amount of time introducing the clearing of the status code in the right places, and the odds are the results will not be perfect on the first pass. Needless to say, I did verify that in my test case, where the server never responds to the connect request, the error number is returned and the status code of failure is now returned all the way out through the generated adb stubs to the application. The attached diff was incorporated in svn rev 619201. > On in-out message flow that fails with no response, no error code or > misleading error code is returned, expected error number 3. > -- > > Key: AXIS2C-791 > URL: https://issues.apache.org/jira/browse/AXIS2C-791 > Project: Axis2-C > Issue Type: Bug > Components: core/clientapi >Affects Versions: 1.1.0 > Environment: Windows XP, Visual Studio 2005 >Reporter: Bill Mitchell >Assignee: Bill Mitchell >Priority: Minor > Fix For: 1.3.0 > > Attachments: diff.txt > > > If a blocking I/O is requested for an in-out message exchange and no response > is received, axis2_svc_client_send_receive et.al. return a zero response > pointer. But one would expect the errno variable to contain some value > indicating the error. > In op_client.c in axis2_op_client_two_way_se
RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue
. What if the server expects the > client to send more? Thus, it is not done to simply ignore it. I think it > is better if we could have a discussion on this on the dev-list. My > concern is with RESTful invocations mainly, where we'd be considering many > status codes unlike SOAP that considers 200, 202, and 500. > > Answering your reverse seek situation. I believe the server requires us to > understand a response in order, and we must understand statuses one-by-one > and if we can't recognize a status we must report an error and exit, > without making any assumptions. > > Also, I believe that this is not a bug in our implementation. Rather, we > need an improvement to understand 100 continue responses. > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html > > Regards, > Senaka > >> libcurl interface assumes first response line is HTTP status, but it >> might be HTTP 100 Continue >> --- >> >> Key: AXIS2C-967 >> URL: https://issues.apache.org/jira/browse/AXIS2C-967 >> Project: Axis2-C >> Issue Type: Bug >> Components: transport/http >> Environment: Windows XP, Visutal Studio 2005, libxml, libcurl >>Reporter: Bill Mitchell >> >> After receiving an HTTP response, the axis2_libcurl code assumes the >> first response line is the HTTP status line, and grabs the status code >> therein. While watching this communicate to an IIS server, I noticed >> that the first response was an HTTP 1.1/100 Continue, and the real >> status line was several lines later. I don't know if IIS sends the 100 >> Continue all of the time or just some of the time; regardless, it is >> allowed in the HTTP RFC 2616. The libcurl code needs to read through to >> find the first non-1xx HTTP status line, or process these headers in >> reverse order and grab the code from the last status line received. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue
I understand your point, Senaka, at least as it raises the idea that we can't just skip all 100 status responses. What if I rephrased the issue to say that we need to get to the last HTTP status line and return it? What I'm seeing stepping through the axis2_libcurl implementation is that the curl library forwards the entire response back to us. So the response list begins with the HTTP 100 response and continues through to read the body. The curl library has already done the job of recognizing the 100 status and continuing. Now, in the case I saw, the subsequent status was 200 and not an issue. But what if it was something else? Because the axis2_libcurl code returns the 100 and discards all the remaining status lines, the 100 will be the only status the upper logic sees. In the SOAP flow, no one cares about the status, so this issue doesn't affect my needs personally. But for whoever does look at it, e.g., the RESTful flow, the fact that it does not get to see a code it is looking for probably matters. Thus my suggestion that, however the status code is used in the upper layers, axis2_libcurl would return the most useful status line by examining the last one it received from the curl library. It may be, as you suggest, that at some point the upper level logic will need access to all the response status lines. And you are right, that is a larger implementation issue. Today, there is some upper level code looking for a 500 status, and in some cases the axis2_libcurl implementation will hide that status and provide the upper level code only the 100 status. Regards, Bill -Original Message- From: Senaka Fernando (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 3:57 AM To: axis-c-dev@ws.apache.org Subject: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue [ https://issues.apache.org/jira/browse/AXIS2C-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566063#action_12566063 ] Senaka Fernando commented on AXIS2C-967: Hi Bill, No it is correct to read the first line. Even a 100 continue is a valid HTTP status, [1]. We must process that and then consider any trailing responses. Processing may be checking whether the client has nothing more to send. We can perhaps log a message. What if the server expects the client to send more? Thus, it is not done to simply ignore it. I think it is better if we could have a discussion on this on the dev-list. My concern is with RESTful invocations mainly, where we'd be considering many status codes unlike SOAP that considers 200, 202, and 500. Answering your reverse seek situation. I believe the server requires us to understand a response in order, and we must understand statuses one-by-one and if we can't recognize a status we must report an error and exit, without making any assumptions. Also, I believe that this is not a bug in our implementation. Rather, we need an improvement to understand 100 continue responses. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Regards, Senaka > libcurl interface assumes first response line is HTTP status, but it might be > HTTP 100 Continue > --- > > Key: AXIS2C-967 > URL: https://issues.apache.org/jira/browse/AXIS2C-967 > Project: Axis2-C > Issue Type: Bug > Components: transport/http > Environment: Windows XP, Visutal Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > > After receiving an HTTP response, the axis2_libcurl code assumes the first > response line is the HTTP status line, and grabs the status code therein. > While watching this communicate to an IIS server, I noticed that the first > response was an HTTP 1.1/100 Continue, and the real status line was several > lines later. I don't know if IIS sends the 100 Continue all of the time or > just some of the time; regardless, it is allowed in the HTTP RFC 2616. The > libcurl code needs to read through to find the first non-1xx HTTP status > line, or process these headers in reverse order and grab the code from the > last status line received. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - 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]
[jira] Created: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue
libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue --- Key: AXIS2C-967 URL: https://issues.apache.org/jira/browse/AXIS2C-967 Project: Axis2-C Issue Type: Bug Components: transport/http Environment: Windows XP, Visutal Studio 2005, libxml, libcurl Reporter: Bill Mitchell After receiving an HTTP response, the axis2_libcurl code assumes the first response line is the HTTP status line, and grabs the status code therein. While watching this communicate to an IIS server, I noticed that the first response was an HTTP 1.1/100 Continue, and the real status line was several lines later. I don't know if IIS sends the 100 Continue all of the time or just some of the time; regardless, it is allowed in the HTTP RFC 2616. The libcurl code needs to read through to find the first non-1xx HTTP status line, or process these headers in reverse order and grab the code from the last status line received. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Applying Patch Fixes to Guththila in 1.3.0
While working on the axis2_libcurl code, I was frequently verifying the SOAP messages in memory on their way to the server, sometimes using the guththila parser and sometimes using libxml. A new behavior I noticed was that one could enable an xml declaration at the front of the xml document using libxml. But this new feature does not seem to work with guththila. Initially I thought this was because the libxml is willing to default the version information when it is passed a character encoding but no version, whereas guththila xml writer treats this as an error. But then I noticed that, beyond this, the guththila_xml_writer has no support at all for generating the xml declaration. Which is understandable; after all, SOAP 1.1 says the xml declaration is not allowed in SOAP messages. Given that this ability to insert the xml declaration is claimed to be a feature of the new release, I take it that this is a bug in guththila that needs to be written up? This might prevent the adoption of guththila as the default parser if it omits support needed for a feature in the new release. Bill Mitchell [EMAIL PROTECTED] From: Dinesh Premalal [mailto:[EMAIL PROTECTED] Sent: Monday, February 04, 2008 5:48 AM To: Apache AXIS C Developers List; [EMAIL PROTECTED] Subject: Re: Applying Patch Fixes to Guththila in 1.3.0 On Feb 4, 2008 4:16 PM, Senaka Fernando <[EMAIL PROTECTED]> wrote: Hi all, I see that there are a number of issues, reported and patched when it comes to the Guththila parser. Wouldn't it be better if we could add these to the 1.3.0 release? +1 , May be we can make guththila the default parser after fixing those. thanks, Dinesh -- http://nethu.org/
[jira] Resolved: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell resolved AXIS2C-791.
--
Resolution: Fixed
Fix Version/s: 1.3.0
Fix incorporated in svn rev 618845. To get the send error status returned by
http_transport_sender_write_message out to the client, changes were needed not
only in axis2_engine_send, but in axis2_op_client_add_msg_ctx not to destroy
the error status when a NULL incoming parameter was seen.
> On in-out message flow that fails with no response, no error code or
> misleading error code is returned, expected error number 3.
> --
>
> Key: AXIS2C-791
> URL: https://issues.apache.org/jira/browse/AXIS2C-791
> Project: Axis2-C
> Issue Type: Bug
> Components: core/clientapi
>Affects Versions: 1.1.0
> Environment: Windows XP, Visual Studio 2005
>Reporter: Bill Mitchell
>Assignee: Bill Mitchell
>Priority: Minor
> Fix For: 1.3.0
>
>
> If a blocking I/O is requested for an in-out message exchange and no response
> is received, axis2_svc_client_send_receive et.al. return a zero response
> pointer. But one would expect the errno variable to contain some value
> indicating the error.
> In op_client.c in axis2_op_client_two_way_send() there is code at the very
> end, when there is no response envelope, to ensure that an error code is
> returned:
> if (AXIS2_ERROR_GET_STATUS_CODE(env->error) != AXIS2_SUCCESS)
> {
> AXIS2_ERROR_SET(env->error,
>
> AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
> AXIS2_FAILURE);
> if (engine)
> {
> axis2_engine_free(engine, env);
> engine = NULL;
> }
> axis2_msg_ctx_free(response, env);
> return NULL;
> }
> As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the
> intent is to return error number 3 when no other error has been diagnosed.
> Unfortunately, even after this fix, in the nightly build of 11/27/07, there
> is a new bug that causes error number 3 to be replaced with an uninformative
> error 2, invalid null parameter. In svc_client, when the empty response is
> returned, axis2_op_client_add_msg_ctx() is called with an intentional null
> value clear the ctx.
> In the post 1.1 source, parameter validation has been added to
> axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_op_client_add_msg_ctx(
> axis2_op_client_t * op_client,
> const axutil_env_t * env,
> axis2_msg_ctx_t * mc)
> {
> axis2_msg_ctx_t *out_msg_ctx = NULL,
> *in_msg_ctx = NULL;
> axis2_msg_ctx_t **msg_ctx_map = NULL;
> AXIS2_PARAM_CHECK (env->error, op_client, AXIS2_FAILURE);
> AXIS2_PARAM_CHECK (env->error, mc, AXIS2_FAILURE);
> The second AXIS2_PARAM_CHECK should be removed.
> After making both these changes in the development shapshot, when the client
> receives no response, for example if the URL points to a non-running server,
> the client correctly receives error 3, Blocking invocation expects response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565776#action_12565776
]
Bill Mitchell commented on AXIS2C-791:
--
Okay, Senaka, you may indeed have run across the same problems I did. I intend
to pick this issue up again today, now that I've checked-in fixes to the
guththila issues I reported.
> On in-out message flow that fails with no response, no error code or
> misleading error code is returned, expected error number 3.
> --
>
> Key: AXIS2C-791
> URL: https://issues.apache.org/jira/browse/AXIS2C-791
> Project: Axis2-C
> Issue Type: Bug
> Components: core/clientapi
>Affects Versions: 1.1.0
> Environment: Windows XP, Visual Studio 2005
>Reporter: Bill Mitchell
>Assignee: Bill Mitchell
>Priority: Minor
>
> If a blocking I/O is requested for an in-out message exchange and no response
> is received, axis2_svc_client_send_receive et.al. return a zero response
> pointer. But one would expect the errno variable to contain some value
> indicating the error.
> In op_client.c in axis2_op_client_two_way_send() there is code at the very
> end, when there is no response envelope, to ensure that an error code is
> returned:
> if (AXIS2_ERROR_GET_STATUS_CODE(env->error) != AXIS2_SUCCESS)
> {
> AXIS2_ERROR_SET(env->error,
>
> AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
> AXIS2_FAILURE);
> if (engine)
> {
> axis2_engine_free(engine, env);
> engine = NULL;
> }
> axis2_msg_ctx_free(response, env);
> return NULL;
> }
> As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the
> intent is to return error number 3 when no other error has been diagnosed.
> Unfortunately, even after this fix, in the nightly build of 11/27/07, there
> is a new bug that causes error number 3 to be replaced with an uninformative
> error 2, invalid null parameter. In svc_client, when the empty response is
> returned, axis2_op_client_add_msg_ctx() is called with an intentional null
> value clear the ctx.
> In the post 1.1 source, parameter validation has been added to
> axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_op_client_add_msg_ctx(
> axis2_op_client_t * op_client,
> const axutil_env_t * env,
> axis2_msg_ctx_t * mc)
> {
> axis2_msg_ctx_t *out_msg_ctx = NULL,
> *in_msg_ctx = NULL;
> axis2_msg_ctx_t **msg_ctx_map = NULL;
> AXIS2_PARAM_CHECK (env->error, op_client, AXIS2_FAILURE);
> AXIS2_PARAM_CHECK (env->error, mc, AXIS2_FAILURE);
> The second AXIS2_PARAM_CHECK should be removed.
> After making both these changes in the development shapshot, when the client
> receives no response, for example if the URL points to a non-running server,
> the client correctly receives error 3, Blocking invocation expects response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cloning a portion of a XML tree using axiom
Hi Kasun, In my application I found I had a similar need to clone all of an axiom sub-tree. Unlike the Xerces C++ package, the Axiom C package doesn't have a built-in clone method. Axiom does have all the underlying methods, though, to traverse the tree and build new nodes that replicate the old nodes, so I wrote my own clone. Along the way I discovered that I needed something more specialized than a general clone, to conditionally keep or discard attributes and text associated with elements. As well, I had to avoid some of the Axiom methods, particularly the iterator methods, as I am sometimes sharing the one source document across multiple threads. As I was writing in C++, the end result isn't suitable to be a contribution to Axiom. The code throws exceptions to handle errors, instead of the Axis/Axiom C technique of returning status codes. Recursively traversing the tree to clone each subtree is pretty straightforward, but looking at my code could give you a jump start on handling namespaces and attributes as the nodes and elements are reached along the way. If you want a copy of the routines I wrote, I can send them to you as an attachment off-list. If you are going to a C environment, you will need to replace all the error handling and the C++ style comments; if you are in a C++ environment, replacing the exceptions with something from your environment will be straightforward. Bill Mitchell [EMAIL PROTECTED] From: Kasun Indrasiri [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 5:32 AM To: Apache AXIS C Developers List Subject: Re: Cloning a portion of a XML tree using axiom Hi, In the case of using axiom_element_get_children_with_qname(...) method, once the initial axiom_node is freed (say sec-policy is freed in above example) then the node that we extracted through the iterator (which is to be used for WS-Trust ) will be also freed. What I really want to acheive is this. - Initially I got an axiom_node which contains .. and I want to get a new copy (separate memory allocation) of a content of that node (say things with the qname ). - And also once the main node is freed, the extracted part should not be freed. - I wonder whether Jimmy's solution would work with axiom. Thanks, Kasun.
[jira] Resolved: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
[
https://issues.apache.org/jira/browse/AXIS2C-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell resolved AXIS2C-944.
--
Resolution: Fixed
Assignee: Bill Mitchell
This fix has been applied as svn rev 618521.
> guththila parser ignores XML scope rules on namespace declarations with the
> same prefix
> ---
>
> Key: AXIS2C-944
> URL: https://issues.apache.org/jira/browse/AXIS2C-944
> Project: Axis2-C
> Issue Type: Bug
> Components: guththila
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
>Reporter: Bill Mitchell
>Assignee: Bill Mitchell
> Fix For: 1.3.0
>
> Attachments: diff.txt
>
>
> The guththila parser looks for a match on the namespace prefix/URI from the
> outermost element inwards. This violates the scope rules for XML namespaces,
> see http://www.w3.org/TR/REC-xml-names/. This problem holds for both
> incoming messages in guththila_xml_parser.c and outgoing messages in
> guththila_xml_writer.c. Essentially every loop involving
> guththila_stack_get_by_index() is suspect, and either needs to start at
> (stack_size - 1) and go backwards, or fetch the namespace at the (stack_size
> - 1 - i) index.
> I uncovered this by inspection, not by testing, so there is some chance that
> my understanding is incorrect. But I looked at guththila_stack.c and indeed
> for index 0 it returns the outermost/first element pushed, so there is no
> tricky logic there to get the stack in the other order. Of course, one could
> indeed fix this problem by changing guththila_stack_get_by_index() to return
> the elements from the innermost/most recently pushed back out to the
> outermost. This would be the easiest fix to make, and the safest in that it
> would not change the logic in any of the existing loops, although it would
> seem less clear to the casual reader.
> In other words, the current logic:
> guththila_stack_get_by_index(
> guththila_stack_t * stack,
> int index,
> const axutil_env_t * env)
> {
> return index < stack->top ? stack->data[index] : NULL;
> }
> could be changed to read:
> {
> return index < stack->top ? stack->data[stack->top - index - 1] : NULL;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
[
https://issues.apache.org/jira/browse/AXIS2C-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-944:
-
Attachment: diff.txt
The attached diff contains changes to conform to the XML namespace scope rules
by searching the namespace stack from the inside out.
As well, having enabled warning messages in the Windows NMAKE makefile, I have
fixed several mismatched signed/unsigned conflicts that the compiler diagnosed.
And the relatively new guththila_token_close routines were moved intact after
the expected first entry points of create/init/free.
> guththila parser ignores XML scope rules on namespace declarations with the
> same prefix
> ---
>
> Key: AXIS2C-944
> URL: https://issues.apache.org/jira/browse/AXIS2C-944
> Project: Axis2-C
> Issue Type: Bug
> Components: guththila
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
>Reporter: Bill Mitchell
> Fix For: 1.3.0
>
> Attachments: diff.txt
>
>
> The guththila parser looks for a match on the namespace prefix/URI from the
> outermost element inwards. This violates the scope rules for XML namespaces,
> see http://www.w3.org/TR/REC-xml-names/. This problem holds for both
> incoming messages in guththila_xml_parser.c and outgoing messages in
> guththila_xml_writer.c. Essentially every loop involving
> guththila_stack_get_by_index() is suspect, and either needs to start at
> (stack_size - 1) and go backwards, or fetch the namespace at the (stack_size
> - 1 - i) index.
> I uncovered this by inspection, not by testing, so there is some chance that
> my understanding is incorrect. But I looked at guththila_stack.c and indeed
> for index 0 it returns the outermost/first element pushed, so there is no
> tricky logic there to get the stack in the other order. Of course, one could
> indeed fix this problem by changing guththila_stack_get_by_index() to return
> the elements from the innermost/most recently pushed back out to the
> outermost. This would be the easiest fix to make, and the safest in that it
> would not change the logic in any of the existing loops, although it would
> seem less clear to the casual reader.
> In other words, the current logic:
> guththila_stack_get_by_index(
> guththila_stack_t * stack,
> int index,
> const axutil_env_t * env)
> {
> return index < stack->top ? stack->data[index] : NULL;
> }
> could be changed to read:
> {
> return index < stack->top ? stack->data[stack->top - index - 1] : NULL;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-859. -- Resolution: Fixed Assignee: Bill Mitchell I checked in Lahiru and my fixes to guththila_xml_parser and guththila_xml_writer in svn rev 618378. > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Assignee: Bill Mitchell > Fix For: 1.3.0 > > Attachments: diff.txt, diff_1.txt, diff_2.txt, > guththila_xml_writer.diff > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565466#action_12565466 ] Bill Mitchell commented on AXIS2C-933: -- Fix included in svn rev 618364. > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell >Assignee: Bill Mitchell > Fix For: 1.3.0 > > Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-812) guththila parser fails attempting to deallocate unallocated cell if xml message contains more than one namespace
[ https://issues.apache.org/jira/browse/AXIS2C-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-812. -- Resolution: Fixed Fix Version/s: 1.3.0 > guththila parser fails attempting to deallocate unallocated cell if xml > message contains more than one namespace > > > Key: AXIS2C-812 > URL: https://issues.apache.org/jira/browse/AXIS2C-812 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows, Visual Studio 2005, guththila validating parser >Reporter: Bill Mitchell > Fix For: 1.3.0 > > Attachments: guththila_xml_parser_diff, guththila_xml_parser_diff_2 > > > The guththila validating parser fails attempting to deallocate an unallocated > cell if the xml message constains more than one namespace. The issue is that > the validating parser allocates one cell of memory to hold an array of > namespaces, but that the code that frees the namespaces believes that each > array element is a separate cell. Thus, if the array contains more than one > element, the free of the second element fails. > One can see the problem when parsing a SOAP response message identifying two > namespaces, e.g., one that begins: > > - http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";> > - > ... > This appears to be a problem introduced as part of fix AXIS2C-785 since 1.1.0 > in the development branch; in 1.1.0 the array was not freed at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-933. -- Resolution: Fixed Assignee: Bill Mitchell > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell >Assignee: Bill Mitchell > Fix For: 1.3.0 > > Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: guththila_xml_parser.diff For reference, in the attached guththila_xml_parser.diff is the patch to just the problems described in this issue. I will apply it shortly. > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Fix For: 1.3.0 > > Attachments: diff.txt, diff2.txt, guththila_xml_parser.diff > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: diff2.txt Supun, I see the cause of the confusion. When I uploaded a revised version of this patch, I mistakenly did not strip all the fixes to other modules from this patch. My bad. I've fixed that error in the diff2.txt file, so it is just this fix combined with the fix already applied later to guththila for AXIS2C-857. So you can examine this to see if anything strikes you as really odd. Later today, I should have a chance to rebuild the patch against the current guththila_xml_parser.c source, so the patch will then include just this fix and not AXIS2C-857. > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff2.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: (was: diff2.txt) > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-859: - Attachment: (was: diff_2.txt) > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff_1.txt, diff_2.txt, > guththila_xml_writer.diff > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-859: - Attachment: diff_2.txt > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff_1.txt, diff_2.txt, > guththila_xml_writer.diff > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-859: - Attachment: guththila_xml_writer.diff diff_2.txt Lahiru, looking at the code again, I now agree that you were right to replace the character by sliding the token data down. I was under the mistaken impression that the code was sliding all the rest of the buffer down; as long as we are sliding from one end or the other of the token, there is no reason not do the obvious slide down. In the attached diff_2.txt, I moved the code to perform the replacement into a lower level routine. As guththila_close_token has constructed a temp token in both the text case and the attribute value case, it is easy to perform replacement on this temp token string before further processing of the attribute for a namespace declaration. Beware that the line number where we change the token type to _text may be different in yours; my version includes changes for AXIS2C-933 that Supun wants to review before they are applied. Separately, in the attached guththila_xml_writer.diff, is a patch to other side of this issue, the insertion of character sequences on outgoing messages that include ampersand or greater than in the text. With both fixes installed, I was able to see ampersand data characters from the client arrive at the server intact, and vice versa. > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff_1.txt, diff_2.txt, > guththila_xml_writer.diff > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564962#action_12564962 ] Bill Mitchell commented on AXIS2C-857: -- I noticed that along the way a change in Lahiru's patch to fix guththila_tok_tok_cmp to scan all the characters in the token was not applied in the final patch. This fix is now restored in svn rev 617685. > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal >Priority: Minor > Fix For: 1.2.1 > > Attachments: diff.txt, diff2.txt, diff_mod.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-861. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix to this problem has been incorporated in svn revision 617668. There is still the minor issue that performing the curl_global_init call in axis2_libcurl.c is the best that can be done in the current architecture, but is not perfect as it should be done where one is guaranteed to be single threaded. Absent hooks to do this when the http transport layer is loaded, the only single threaded point is outside in the client application. If the client application does the call to curl_global_init explicitly itself, the second call here in axis2_libcurl.c doesn't hurt. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Fix For: Current (Nightly) > > Attachments: libcurl.diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-830) libcurl interface not multithreaded
[ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-830. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix to this problem has been incorporated in svn revision 617668. > libcurl interface not multithreaded > --- > > Key: AXIS2C-830 > URL: https://issues.apache.org/jira/browse/AXIS2C-830 > Project: Axis2-C > Issue Type: Bug > Components: transport/http >Affects Versions: 1.1.0 > Environment: Windows XP, Visual Studio 2005, build uses libcurl and > guththila >Reporter: Bill Mitchell > Fix For: Current (Nightly) > > Attachments: libcurl_diff > > > Axis2C support of libcurl is not multithreaded, i.e., it cannot be invoked by > a multithreaded client application. This despite the fact that libcurl is > multithreaded and Axis2C is multithreaded. The crux of the issue lies in the > static global definition of the curl handler in axis2_libcurl.c. This > prevents multiple client threads from obtaining multiple connections to issue > concurrent SOAP operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-834) guththila_xml_writer has problems with default namespace
[ https://issues.apache.org/jira/browse/AXIS2C-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-834. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix has been incorporated in svn rev 617651. > guththila_xml_writer has problems with default namespace > > > Key: AXIS2C-834 > URL: https://issues.apache.org/jira/browse/AXIS2C-834 > Project: Axis2-C > Issue Type: Bug > Components: guththila, xml/parser >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, > libcurl transport >Reporter: Bill Mitchell > Fix For: Current (Nightly) > > Attachments: guththila_xml_writer_diff, > guththila_xml_writer_wrapper_diff > > > The guththila xml writer appears to have several problems related to the > default namespace. These appear when attempting to use the ADB stubs for the > elements in the SOAP request messages, as the Axis data bindings fill in the > default namespace from the WSDL. > (1) In guththila_xml_writer_wrapper, guththila_xml_writer_wrap_namespace() > has a comment indicating that the prefix is null on the default namespace. > Yet it goes ahead and calls guththila_write_namespace() which requires both a > prefix and a namespace URI. > (2) In guththila_xml_wrapper.c, the routine > guththila_write_start_element_with_namespace() does not understand the > default namespace. It searches the table of namespaces to determine the > prefix that goes with this namespace. If the namespace is not found, no XML > is generated, so no element is started although the outer code assumes it is. > This results in malformed XML as below: > http://schemas.xmlsoap.org/soap/envelope/";> > > xmlns="http://frameware.xcentrisity.com/services/";> > Yes, the trailing elements in the stack without having started one of the elements, this is the > outcome. > (3) After fixing the above problems, I discovered that the generated XML for > the element inside the SOAP Body incorrectly had the URI of the namespace as > the name of the element, rather than the name itself. I.e., the message > contained a structure like: > http://schemas.xmlsoap.org/soap/envelope/";> > > > <http://frameware.xcentrisity.com/services/ name="customer" > exemplarHandle="master" > xmlns="http://frameware.xcentrisity.com/services/";>http://frameware.xcentrisity.com/services/> > > > The problem is that > guththila_xml_writer_wrapper_start_element_with_namespace() is not flipping > the order of the parameters as is correctly done in > guththila_xml_writer_wrapper_start_element_with_namespace_prefix(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-818) If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer
[ https://issues.apache.org/jira/browse/AXIS2C-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell resolved AXIS2C-818. -- Resolution: Fixed Fix Version/s: Current (Nightly) This fix has been applied as svn revision 617570. > If the returned message read fills the buffer, http_transport_utils.c > clobbers the byte past the end of the buffer > -- > > Key: AXIS2C-818 > URL: https://issues.apache.org/jira/browse/AXIS2C-818 > Project: Axis2-C > Issue Type: Bug > Components: transport/http >Affects Versions: 1.1.0 > Environment: Windows, Visual Studio 2005, debug build, libcurl > enabled, guththila parser enabled >Reporter: Bill Mitchell > Fix For: Current (Nightly) > > Attachments: http_transport_utils_diff > > > If the returned message from libcurl exceeds 4096 characters, the size of a > guththila buffer, http_transport_utils clobbers the byte following the end of > the buffer. When running the Windows version in debug mode, this is nicely > diagnosed by the C runtime as a heap corruption failure. > The problem lies in axis2_http_transport_utils_on_data_request() where it > always stores a zero byte past the end of the data read, even if the data > read fully fills the size of the provided buffer. As I don't know the intent > of storing the zero byte, It's not clear to me which of 3 remedies is best: > (1) don't ever store the zero byte, it's past the end of the bytes read > (2) store the zero byte only if fewer characters were read than the size of > the buffer > (3) always read one byte less than the size of the buffer, thus guaranteeing > space for a terminating null byte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
[
https://issues.apache.org/jira/browse/AXIS2C-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1256#action_1256
]
Bill Mitchell commented on AXIS2C-944:
--
Looking at the code in more detail, I see that guththila_xml_writer examines
the namespace 7 times from the outermost to the innermost, and twice the
correct way from the innermost to the outermost. All two times that
guththila_xml_parser.c examines the namespace stack, it does it from the
outermost to the innermost, i.e., in the wrong order.
guththila_get_namespace_prefix_by_number(),
guththila_get_namespace_uri_by_number() makes the use of the number visible to
the caller. These are used by the guththila_main sample program, and
interestingly use 1-origin indexing.
guththila_get_attribute_XXX_by_number() uses the same stack routines, so the
stack construct is not used just for namespaces. As with the
guththila_get_namespace_XXX_by_number() routines, these are used by the
guththila_main sample program and use 1-origin indexing.
Given the additional interface routines that make the numbering scheme visible
publicly, the right solution appears to be to fix the offending loops in
guththila_xml_parser.c and guththila_xml_writer.c to examine the stack from the
higher index down to zero. Not the "clever" solution to number the stack from
the top of the stack backwards.
> guththila parser ignores XML scope rules on namespace declarations with the
> same prefix
> ---
>
> Key: AXIS2C-944
> URL: https://issues.apache.org/jira/browse/AXIS2C-944
> Project: Axis2-C
> Issue Type: Bug
> Components: guththila
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
>Reporter: Bill Mitchell
>
> The guththila parser looks for a match on the namespace prefix/URI from the
> outermost element inwards. This violates the scope rules for XML namespaces,
> see http://www.w3.org/TR/REC-xml-names/. This problem holds for both
> incoming messages in guththila_xml_parser.c and outgoing messages in
> guththila_xml_writer.c. Essentially every loop involving
> guththila_stack_get_by_index() is suspect, and either needs to start at
> (stack_size - 1) and go backwards, or fetch the namespace at the (stack_size
> - 1 - i) index.
> I uncovered this by inspection, not by testing, so there is some chance that
> my understanding is incorrect. But I looked at guththila_stack.c and indeed
> for index 0 it returns the outermost/first element pushed, so there is no
> tricky logic there to get the stack in the other order. Of course, one could
> indeed fix this problem by changing guththila_stack_get_by_index() to return
> the elements from the innermost/most recently pushed back out to the
> outermost. This would be the easiest fix to make, and the safest in that it
> would not change the logic in any of the existing loops, although it would
> seem less clear to the casual reader.
> In other words, the current logic:
> guththila_stack_get_by_index(
> guththila_stack_t * stack,
> int index,
> const axutil_env_t * env)
> {
> return index < stack->top ? stack->data[index] : NULL;
> }
> could be changed to read:
> {
> return index < stack->top ? stack->data[stack->top - index - 1] : NULL;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-944) guththila parser ignores XML scope rules on namespace declarations with the same prefix
guththila parser ignores XML scope rules on namespace declarations with the
same prefix
---
Key: AXIS2C-944
URL: https://issues.apache.org/jira/browse/AXIS2C-944
Project: Axis2-C
Issue Type: Bug
Components: guththila
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
The guththila parser looks for a match on the namespace prefix/URI from the
outermost element inwards. This violates the scope rules for XML namespaces,
see http://www.w3.org/TR/REC-xml-names/. This problem holds for both incoming
messages in guththila_xml_parser.c and outgoing messages in
guththila_xml_writer.c. Essentially every loop involving
guththila_stack_get_by_index() is suspect, and either needs to start at
(stack_size - 1) and go backwards, or fetch the namespace at the (stack_size -
1 - i) index.
I uncovered this by inspection, not by testing, so there is some chance that my
understanding is incorrect. But I looked at guththila_stack.c and indeed for
index 0 it returns the outermost/first element pushed, so there is no tricky
logic there to get the stack in the other order. Of course, one could indeed
fix this problem by changing guththila_stack_get_by_index() to return the
elements from the innermost/most recently pushed back out to the outermost.
This would be the easiest fix to make, and the safest in that it would not
change the logic in any of the existing loops, although it would seem less
clear to the casual reader.
In other words, the current logic:
guththila_stack_get_by_index(
guththila_stack_t * stack,
int index,
const axutil_env_t * env)
{
return index < stack->top ? stack->data[index] : NULL;
}
could be changed to read:
{
return index < stack->top ? stack->data[stack->top - index - 1] : NULL;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell reopened AXIS2C-857: -- Probably thanks to Lahira and I cooperating to work on the patch, we ended up with a version in diff.txt that introduced the logic to create an xml: namespace declaration twice in guththila_init(). Obviously one of the two identical blocks of following code needs to be removed. Starting with temp_name = guththila_token_create(GUTHTHILA_XML_NAME,0,strlen(GUTHTHILA_XML_NAME), 1,0,0,env); temp_tok = guththila_token_create(GUTHTHILA_XML_URI,0,strlen(GUTHTHILA_XML_URI), 1,0,0,env); through the end of the new code at: e_namesp = NULL; } return GUTHTHILA_FAILURE; } > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl > Reporter: Bill Mitchell >Assignee: Dinesh Premalal >Priority: Minor > Fix For: 1.2.1 > > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564199#action_12564199 ] Bill Mitchell commented on AXIS2C-859: -- Lahira, after yesterday I researched again the XML spec and I find that it says that replacement of XML characters and entity references happens on the URI to generate the normalized value. So it seems we have to do this character replacement logic on the attribute value string before we process it as a possible namespace declaration. Just another extra wrinkle. My "second" item above alluded to a different solution, built into guththila_next() instead of guththila_token_close(). One could imagine, in the "right" loops in guththila_next where we are looking at the characters one at a time anyway, we could detect the leading ampersand, check the next 4 or 5 characters against the XML character reference values, and replace the character there, again as above sliding the leading part of the token to abut the smaller single character. This would avoid a second pass over the token characters looking for the ampersands, but I suspect it would make guththila_next() much harder to understand than it already is. So my second point above was just to say that I think you have chosen the better approach, to handle this issue of XML character entities in guthtila_token_close() well separate from the token parsing in guththila_next(). > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-927) axiom_element_declare_default_namespace fails when no namespace already declared
[
https://issues.apache.org/jira/browse/AXIS2C-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564188#action_12564188
]
Bill Mitchell commented on AXIS2C-927:
--
Although the source fix is obvious, I did verify it against a testcase. After
downloading the updated sources, I regenerated my testcase for this by
modifying one of the generated stubs and verified that it works correctly as
applied, at least in the presence of a fix for AXIS2C-834 for guththila.
> axiom_element_declare_default_namespace fails when no namespace already
> declared
>
>
> Key: AXIS2C-927
> URL: https://issues.apache.org/jira/browse/AXIS2C-927
> Project: Axis2-C
> Issue Type: Bug
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
> Reporter: Bill Mitchell
>Assignee: Dinesh Premalal
> Fix For: 1.2.1
>
> Attachments: om_element_diff
>
>
> If axiom_element_declare_default_namespace() is called before any named
> namespace is declared, it fails to perform the axutil_hash_make and as a
> result axutil_hash_set crashes on the empty namespace pointer.
> The code fragment:
> if (om_element->namespaces)
> {
> om_element->namespaces = axutil_hash_make(env);
> if (!(om_element->namespaces))
> {
> return NULL;
> }
> }
> should read:
> if (!om_element->namespaces)
> {
> om_element->namespaces = axutil_hash_make(env);
> if (!(om_element->namespaces))
> {
> return NULL;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-925) seg fault in axiom_soap_fault_get_text if SOAP 1.1
[ https://issues.apache.org/jira/browse/AXIS2C-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564151#action_12564151 ] Bill Mitchell commented on AXIS2C-925: -- I updated to newer sources, retested, recreated the SOAP 1.1 fault situation and verified that it is handled correctly. Thanks, Dinesh. > seg fault in axiom_soap_fault_get_text if SOAP 1.1 > -- > > Key: AXIS2C-925 > URL: https://issues.apache.org/jira/browse/AXIS2C-925 > Project: Axis2-C > Issue Type: Bug > Components: xml/soap >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml2, libcurl >Reporter: Bill Mitchell >Assignee: Dinesh Premalal > Fix For: 1.2.1 > > Attachments: soapfault.diff > > > If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the > client calls axiom_soap_fault_get_text. At the time of the crash, using the > debugger the om_ele_node in the fault_value points to memory that has been > reused, probably as a result of being released. When axiom_element_get_text > is called, the data_element it is passed appears to be overwritten or reused, > so axiom_element_get_text sees om_element->text_value as nonzero, tries to > free it, and the C runtime diagnoses a memory management error on the free. > Stepping through with the debugger, the crux of the problem lies in > soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the > fault_value_node, converts its contents to text, issues the free_tree to free > the node and its children, but leaves the pointer as the > axiom_soap_fault_value_base_node. So the later call to > axiom_soap_fault_get_text believes there is still a node tree structure > present. The same oversight occurs when processing the fault_reason. The > axiom_soap_fault_text_base_node is detached, converted to a single text > string, the node tree is freed, but the pointer is left as the > axiom_soap_fault_base_node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-861: - Attachment: (was: libcurl_diff) > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl > Reporter: Bill Mitchell > Attachments: libcurl.diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-861: - Attachment: libcurl.diff I am attaching a new libcurl.diff patch that merges all the changes for this issue and AXIS2C-830 with the changes already made to add http header support in AXIS2C-828. This involved separating the release of read headers, which needs to happen on every request, from the release of the axis2_libcurl structure, that now persists throughout the session. If there are no objections, I will go ahead and commit these as soon as I finish resolving my svn setup/infrastructure issues. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl > Reporter: Bill Mitchell > Attachments: libcurl.diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (AXIS2C-861) Enable client session management through http cookies in libcurl
I have updated changes that merge in the new support of HTTP headers in axis2_libcurl.c. But before checking anything in, I wanted to research the convention for revision comments, and what to do to make sure I don't mess up the file by inserting DOS carriage return characters. It appears to me from SVN documentation that the DOS end-of-line sequences inserted by Visual Studio should be cleaned up automatically, provided svn:eol-style is set to native. And the Apache recommendations seem to encourage this to be setup correctly when the files are first created. But, at least on the first file I checked, I couldn't see that the eol-style property was set. So, what is the convention here? Do we not worry about this? Or should we run dos2unix to clean up files before checking them in from Windows? Thanks, Bill Mitchell -Original Message- From: Dinesh Premalal (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 3:08 AM To: [EMAIL PROTECTED] Subject: [jira] Commented: (AXIS2C-861) Enable client session management through http cookies in libcurl [ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563909#action_12563909 ] Dinesh Premalal commented on AXIS2C-861: Hi Bill, I tried to commit this patch, but I couldn't. I think some line numbers are changed. If you could find some time please commit it. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Attachments: libcurl_diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
[ https://issues.apache.org/jira/browse/AXIS2C-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563745#action_12563745 ] Bill Mitchell commented on AXIS2C-859: -- Thanks for picking up this issue, Lahiru. I was thinking about starting to look at it in detail myself. Examining the patch, I have a couple thoughts. First, you allocate a block of memory, escape_char, to hold the copy of the token to this point. But the size of the block is 4 on most machines, the sizeof a pointer to char. So this size will frequently not be enough to copy all the characters preceding the escaped character. It occurs to me that guththila tries to go to a lot of effort to avoid allocating memory. Having worked on some issues recently in the buffer management code, I would propose a different solution: moving the data in the buffer itself. Although the obvious solution would be to replace the escaped sequence with the intended character and slide the remainder of the buffer down, this could be timeconsuming. A clever idea might be to replace the escaped sequence, placing the intended character at the end of the sequence, and copy the characters up from the start of the token, moving the token start up and reducing its size. In most cases, this would not be a large amount of data to move, and it avoids the memory allocation entirely. Second, I like where you chose to insert this code, in the token_close logic. Although I can imagine trying to make this part of guththila_next, where it could massage the buffer contents while it was deciding where the token boundaries are, it seems best to leave that logic deciding where the edges of the tokens are without changing the characters inside the tokens. Third, looking at the examples of character escaping in various texts, it appears that one can find escaped character sequences in text and in attribute values. So this logic either needs to be duplicated, not pretty, or pushed down into a lower level shared routine. Fourth, you inserted this logic in the _char_data: case. It appears to me from the XML documentation that we are supposed to replace sequences in text, but not in comments. guththila_next() seems to confuse this issue, as it treats them both as _char_data. To distinguish the two, my guess is it would be better to define a new token type, rather than cheat and look at the m->guththila_event to tell them apart. A new token type might point the direction to solving the CDATA problem, whenever that gets approached. Maybe use _char_data for the raw char data, without processing, and a new _text_data for char data that undergoes processing of entity sequences. Fifth, when checking the following characters after the ampersand, it would be best to check first that enough characters are left in the token, before looking at the characters themselves and perhaps falling off the end of the buffer. Of course, I'm relatively new to this logic, so these are just my observations. > guththila parser fails to handle escape sequences for ampersand, less than, > greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt > > > When an incoming message contains within text the escaped ampersand sequence, > "&", this sequence is being passed to the client as raw text without > being converted to the single ampersand character. Clearly, this action must > take place at the level of the parser, as only the parser knows whether it is > seeing simple text, and conversion is required, or text embedded in a CDATA > section, where conversion is not allowed. I have tested the build with the > libxml parser, and of course the libxml parser behaves correctly: the text > passed to the client contains only the single ampersand character, not the > escaped sequence. (See section 2.4 of XML 1.0 spec.) > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input and > output. I also don't see where CDATA sections are handled, but as I am not > seeing CDATA in the messages from the service I am hitting, I have not tested > this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
[
https://issues.apache.org/jira/browse/AXIS2C-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563044#action_12563044
]
Bill Mitchell commented on AXIS2C-936:
--
Looking at this again in the log, it would be more clear if the error message
read something like:
"element getExemplarResponse is not complete".
> On incomplete response message, the client receives response data for the
> elements up to the error, but no indication of the error
> --
>
> Key: AXIS2C-936
> URL: https://issues.apache.org/jira/browse/AXIS2C-936
> Project: Axis2-C
> Issue Type: Bug
> Components: code generation
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, libxml or guththila,
> libcurl
>Reporter: Bill Mitchell
>
> If the SOAP response message to the client is incomplete, i.e., there is an
> EOF indication in the middle of the message, the client receives an object
> containing the elements that could be deserialized from the message, with no
> indication that the message is incomplete. Clearly, the impact is that the
> client may act on the partial message, with no indication anywhere that data
> was lost.
> I considered whether this could be fixed in svc_client.c. Although it
> appears with the debugger that the message is usually complete when at the
> end of axis2_svc_client_send_receive_with_op_qname(), this appears to be an
> accident of the fact that the lower level code looks for a soap fault in the
> soap body, and a SOAP 1.1 response does not have a fault in the body so the
> entire body is scanned first looking for the fault. I believe the intent is
> that the response be returned without scanning all of the tokens in the body.
> So it must be the responsibility of the generated stubs to check that all
> the data is processed when deserializing the elements.
> At the end of the deserialize method for the response message, there is code
> like the following:
> if(AXIS2_FAILURE == status)
> {
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value
> for getExemplarResponse ");
> if(element_qname)
> {
> axutil_qname_free(element_qname, env);
> }
> return AXIS2_FAILURE;
> }
> }
> else if(!dont_care_minoccurs)
> {
> if(element_qname)
> {
> axutil_qname_free(element_qname, env);
> }
> /* this is not a nillable element*/
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0
> element getExemplarResponse missing");
> return AXIS2_FAILURE;
> }
> My suggestion is that an additional test for node complete be added similar
> to this:
> if(AXIS2_FAILURE == status)
> {
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value
> for getExemplarResponse ");
> ...
> }
> if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
> {
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire
> element getExemplarResponse ");
> if(element_qname)
> {
> axutil_qname_free(element_qname, env);
> }
> return AXIS2_FAILURE;
> }
> }
> else if(!dont_care_minoccurs)
> ...
> It would probably be reasonable and safe to do this as part of all the
> generated deserialize routines. But in testing it appears sufficient to do
> this in the outermost response element routine, as this assures an error is
> returned to the client if the response message is incomplete.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563043#action_12563043 ] Bill Mitchell commented on AXIS2C-933: -- The issue I alluded to above, that after applying the attached fix the client sees a partial message and no error, is reported separately in AXIS2C-936. > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff2.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-936) On incomplete response message, the client receives response data for the elements up to the error, but no indication of the error
On incomplete response message, the client receives response data for the
elements up to the error, but no indication of the error
--
Key: AXIS2C-936
URL: https://issues.apache.org/jira/browse/AXIS2C-936
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Windows XP, Visual Studio 2005, libxml or guththila,
libcurl
Reporter: Bill Mitchell
If the SOAP response message to the client is incomplete, i.e., there is an EOF
indication in the middle of the message, the client receives an object
containing the elements that could be deserialized from the message, with no
indication that the message is incomplete. Clearly, the impact is that the
client may act on the partial message, with no indication anywhere that data
was lost.
I considered whether this could be fixed in svc_client.c. Although it appears
with the debugger that the message is usually complete when at the end of
axis2_svc_client_send_receive_with_op_qname(), this appears to be an accident
of the fact that the lower level code looks for a soap fault in the soap body,
and a SOAP 1.1 response does not have a fault in the body so the entire body is
scanned first looking for the fault. I believe the intent is that the response
be returned without scanning all of the tokens in the body. So it must be the
responsibility of the generated stubs to check that all the data is processed
when deserializing the elements.
At the end of the deserialize method for the response message, there is code
like the following:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value
for getExemplarResponse ");
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
{
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
/* this is not a nillable element*/
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "non nillable or minOuccrs != 0
element getExemplarResponse missing");
return AXIS2_FAILURE;
}
My suggestion is that an additional test for node complete be added similar to
this:
if(AXIS2_FAILURE == status)
{
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed in setting the value
for getExemplarResponse ");
...
}
if(axiom_node_is_complete(current_node, env) == AXIS2_FALSE)
{
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "failed to scan entire element
getExemplarResponse ");
if(element_qname)
{
axutil_qname_free(element_qname, env);
}
return AXIS2_FAILURE;
}
}
else if(!dont_care_minoccurs)
...
It would probably be reasonable and safe to do this as part of all the
generated deserialize routines. But in testing it appears sufficient to do
this in the outermost response element routine, as this assures an error is
returned to the client if the response message is incomplete.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-818) If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer
[ https://issues.apache.org/jira/browse/AXIS2C-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-818: - Description: If the returned message from libcurl exceeds 4096 characters, the size of a guththila buffer, http_transport_utils clobbers the byte following the end of the buffer. When running the Windows version in debug mode, this is nicely diagnosed by the C runtime as a heap corruption failure. The problem lies in axis2_http_transport_utils_on_data_request() where it always stores a zero byte past the end of the data read, even if the data read fully fills the size of the provided buffer. As I don't know the intent of storing the zero byte, It's not clear to me which of 3 remedies is best: (1) don't ever store the zero byte, it's past the end of the bytes read (2) store the zero byte only if fewer characters were read than the size of the buffer (3) always read one byte less than the size of the buffer, thus guaranteeing space for a terminating null byte was: If the returned message from libcurl exceeds 4096 characters, the size of a guththila buffer, http_transport_utils clobbers the byte following the end of the buffer. When running the Windows version in debug mode, this is nicely diagnosed by the C runtime as a heap corruption failure. The problem lies in axis2_http_transport_utils_on_data_request() where it always stores a zero byte passed the end of the data read, even if the data read fully fills the size of the provided buffer. As I don't know the intent of storing the zero byte, It's not clear to me which of 3 remedies is best: (1) don't ever store the zero byte, it's past the end of the bytes read (2) store the zero byte only if fewer characters were read than the size of the buffer (3) always read one byte less than the size of the buffer, thus guaranteeing space for a terminating null byte Summary: If the returned message read fills the buffer, http_transport_utils.c clobbers the byte past the end of the buffer (was: If the returned message read fills the buffer, http_transport_utils.c clobbers the byte passed the end of the buffer) > If the returned message read fills the buffer, http_transport_utils.c > clobbers the byte past the end of the buffer > -- > > Key: AXIS2C-818 > URL: https://issues.apache.org/jira/browse/AXIS2C-818 > Project: Axis2-C > Issue Type: Bug > Components: transport/http >Affects Versions: 1.1.0 > Environment: Windows, Visual Studio 2005, debug build, libcurl > enabled, guththila parser enabled >Reporter: Bill Mitchell > Attachments: http_transport_utils_diff > > > If the returned message from libcurl exceeds 4096 characters, the size of a > guththila buffer, http_transport_utils clobbers the byte following the end of > the buffer. When running the Windows version in debug mode, this is nicely > diagnosed by the C runtime as a heap corruption failure. > The problem lies in axis2_http_transport_utils_on_data_request() where it > always stores a zero byte past the end of the data read, even if the data > read fully fills the size of the provided buffer. As I don't know the intent > of storing the zero byte, It's not clear to me which of 3 remedies is best: > (1) don't ever store the zero byte, it's past the end of the bytes read > (2) store the zero byte only if fewer characters were read than the size of > the buffer > (3) always read one byte less than the size of the buffer, thus guaranteeing > space for a terminating null byte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-933) guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Summary: guththila parser does not handle incomplete messages well, leading to an infinite loop or seg fault (was: guththila parser fails when incoming message longer than 16984 characters) > guththila parser does not handle incomplete messages well, leading to an > infinite loop or seg fault > --- > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt, diff2.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-933) guththila parser fails when incoming message longer than 16984 characters
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: diff2.txt I agree, Supun, that I misunderstood the buffs variable as accumulating the size of all the buffers to date. It is in fact the size of just this buffer. And, although I understood the logic of copying the start of the token from the last buffer to the new buffer, I was imagining only the easy case of a short token, where another buffer of the same size works fine. The doubling in size handles the unusual case when a large amount of element content must be copied from the previous buffer. I suspected, after I wrote up the issue, that it was better seen from the last problem forward. As I was unintentionally testing the path of an incomplete message from the service, the core issue is that there are several while loops in guththila that do not exit on end-of-file. So they continue to call guththila_next_char. This infinite loop leads to a secondary failure, as guththila_next_char will allocate another buffer, double in size, on each attempt to read at end-of-file. Eventually this memory allocation fails, but as guththila does not check for memory allocation failure, the ending symptom is a seg fault in the buffer management logic. Attached is a revised version of the first patch, that leaves the buffer doubling logic intact, but remedies all the other issues I described and addressed in the first patch. Having implemented a fix for this, I discovered that the fact that the message is incomplete gets lost in the upper layers, so the client ends up seeing a partial message as if it is the entire message. But that is a different issue that can be addressed separately. > guththila parser fails when incoming message longer than 16984 characters > - > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl > Reporter: Bill Mitchell > Attachments: diff.txt, diff2.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-933) guththila parser fails when incoming message longer than 16984 characters
[ https://issues.apache.org/jira/browse/AXIS2C-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-933: - Attachment: diff.txt It is unfortunately not very easy and maybe not helpful to separate these changes from the ones already underdevelopment for AXIS2C-857. So I didn't try, those changes are also present in this patch. Also included are two small related fixes, to detect and handle the out of memory situation when allocating more buffers, and to forego the initialization of variables not used in the normal next_char path as I expect its performance does matter. > guththila parser fails when incoming message longer than 16984 characters > - > > Key: AXIS2C-933 > URL: https://issues.apache.org/jira/browse/AXIS2C-933 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila, libcurl >Reporter: Bill Mitchell > Attachments: diff.txt > > > The code in the guththila parser has a couple of problems when the first > allocated buffer fills up and it attempts to read more data. First, when > allocating another buffer it doubled the size of all the buffers allocated to > this point, but then recorded the new buffer size as only equal to the size > of all the previous buffers. Second, after fixing the buffer allocation > issue, I discovered that the read into the buffer tried to read as much as > all the buffers to date, instead of just the amount remaining in the buffer > just allocated. There is also a subtle problem in the guththila_next_no_char > routine if last_start is not set, that it did not assure that all the > characters since next are moved to the newly allocated buffer. > While debugging this, because of other issues, I walked through the path of > an unexpected EOF in the middle of the incoming message, and discovered that > several while loops in the parser do not stop on EOF, but just keep reading > and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-933) guththila parser fails when incoming message longer than 16984 characters
guththila parser fails when incoming message longer than 16984 characters - Key: AXIS2C-933 URL: https://issues.apache.org/jira/browse/AXIS2C-933 Project: Axis2-C Issue Type: Bug Components: guththila Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, guththila, libcurl Reporter: Bill Mitchell The code in the guththila parser has a couple of problems when the first allocated buffer fills up and it attempts to read more data. First, when allocating another buffer it doubled the size of all the buffers allocated to this point, but then recorded the new buffer size as only equal to the size of all the previous buffers. Second, after fixing the buffer allocation issue, I discovered that the read into the buffer tried to read as much as all the buffers to date, instead of just the amount remaining in the buffer just allocated. There is also a subtle problem in the guththila_next_no_char routine if last_start is not set, that it did not assure that all the characters since next are moved to the newly allocated buffer. While debugging this, because of other issues, I walked through the path of an unexpected EOF in the middle of the incoming message, and discovered that several while loops in the parser do not stop on EOF, but just keep reading and reading and reading... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-857: - Attachment: diff2.txt Lahira, it's a nice start on a patch; it's certainly in the right direction. In testing it I uncovered a few minor coding errors. In guththila_init(), (a) the declarations needed to come at the start of the block, (b) the namespace size is getting setting wrong, as it needs strlen(), sizeof is rounding up to the next multiple of the machine word, (c) the code did not handle out-of-memory on the token creates. In guththila_token_create, (d) it was allocating the wrong length of for the string and the token structure, and (e) it was not actually returning the pointer to the allocated token to the caller. In the attached diff2.txt, I corrected the coding errors and the client app now sees the xml:id attributes on the elements and can process them. Thanks for getting this started. > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-834) guththila_xml_writer has problems with default namespace
[ https://issues.apache.org/jira/browse/AXIS2C-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561179#action_12561179 ] Bill Mitchell commented on AXIS2C-834: -- Lahiru, AXIS2C-891 identified a guththila problem with default namespaces in received messages; this defect describes a problem in guththila sending messages when a default namespace has been identified. I reverted to the checked-in versions of the guththila_xml_writer and guththila_xml_writer_wrapper. As you can see from the crash below, the problem I described still exists. At the time I wrote this, ADB code generation was not working for me. With changes to the ADB code generation since this defect was written, it has become a little more work to reproduce the problem. The generated stubs assign a prefix "n" to the namespace from the WSDL, so the default namespace case does not arise directly with them. To verify the behavior of the underlying code, I modified the stub to use axiom_element_declare_default_namespace() to assign the URI of the namespace (see AXIS2C-927), commenting out the generated stub code that creates a namespace hash and creates a namespace with a prefix value "n". As you can see from the traceback below, when guththila_xml_writer_wrapper_write_namespace() is called with a prefix pointer of 0, a seg fault occurs in guththila_write_namespace. > msvcr80d.dll!strlen(unsigned char * buf=0x0272d0fc) Line 81Asm guththila.dll!guththila_write_namespace(guththila_xml_writer_s * wr=0x027e43d8, char * prefix=0x, char * uri=0x027e8f90, const axutil_env * env=0x0172b450) Line 794 + 0x9 bytes C axis2_parser.dll!guththila_xml_writer_wrapper_write_namespace(axiom_xml_writer * writer=0x027e21c8, const axutil_env * env=0x0172b450, char * prefix=0x, char * namespace_uri=0x027e8f90) Line 539 C axis2_parser.dll!axiom_xml_writer_write_namespace(axiom_xml_writer * writer=0x027e21c8, const axutil_env * env=0x0172b450, char * prefix=0x, char * namespace_uri=0x027e8f90) Line 173 C axiom.dll!axiom_output_write(axiom_output * om_output=0x027eafb8, const axutil_env * env=0x0172b450, axiom_types_t type=AXIOM_NAMESPACE, int no_of_args=2, ...) Line 532 + 0x17 bytes C axiom.dll!axiom_namespace_serialize(axiom_namespace * om_namespace=0x027e8970, const axutil_env * env=0x0172b450, axiom_output * om_output=0x027eafb8) Line 194 + 0x23 bytes C axiom.dll!axiom_element_serialize_start_part(axiom_element * om_element=0x027e8340, const axutil_env * env=0x0172b450, axiom_output * om_output=0x027eafb8, axiom_node * ele_node=0x027e7d88) Line 805 + 0x11 bytes C axiom.dll!axiom_node_serialize(axiom_node * om_node=0x027e7d88, const axutil_env * env=0x0172b450, axiom_output * om_output=0x027eafb8) Line 383 + 0x18 bytes C axiom.dll!axiom_soap_envelope_serialize(axiom_soap_envelope * soap_envelope=0x027e5180, const axutil_env * env=0x0172b450, axiom_output * om_output=0x027eafb8, int cache=0) Line 330 C axis2_http_sender.dll!axis2_libcurl_send(axis2_libcurl * data=0x0172ec40, axiom_output * om_output=0x027eafb8, const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8, axiom_soap_envelope * out=0x027e5180, const char * str_url=0x0172b6a8, const char * soap_action=0x027ea180) Line 207 C axis2_http_sender.dll!axis2_libcurl_http_send(axis2_libcurl * curl=0x0172ec40, axis2_http_sender * sender=0x027da9b0, const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8, axiom_soap_envelope * out=0x027e5180, const char * str_url=0x0172b6a8, const char * soap_action=0x027ea180) Line 2355 C axis2_http_sender.dll!axis2_http_transport_sender_write_message(axis2_transport_sender * transport_sender=0x0172ebe8, const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8, axis2_endpoint_ref * epr=0x0172b4a8, axiom_soap_envelope * out=0x027e5180, axiom_output * om_output=0x027eafb8) Line 726 + 0x24 bytes C axis2_http_sender.dll!axis2_http_transport_sender_invoke(axis2_transport_sender * transport_sender=0x0172ebe8, const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8) Line 310 + 0x1d bytesC axis2_engine.dll!axis2_engine_send(axis2_engine * engine=0x027e9de0, const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8) Line 179 C axis2_engine.dll!axis2_op_client_two_way_send(const axutil_env * env=0x0172b450, axis2_msg_ctx * msg_ctx=0x027e7fc8) Line 1134 + 0x11 bytesC axis2_engine.dll!axis2_op_client_execute(axis2_op_client * op_client=0x027e34e8, const axutil_env * env=0x0172b450, const int block=1) Line 483 + 0xd bytesC axis2_engine.dll!axis2_svc_client_send_receive_with_op_qname(axis2_svc_client * svc_client=0x01755028, const
[jira] Updated: (AXIS2C-927) axiom_element_declare_default_namespace fails when no namespace already declared
[
https://issues.apache.org/jira/browse/AXIS2C-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-927:
-
Attachment: om_element_diff
> axiom_element_declare_default_namespace fails when no namespace already
> declared
>
>
> Key: AXIS2C-927
> URL: https://issues.apache.org/jira/browse/AXIS2C-927
> Project: Axis2-C
> Issue Type: Bug
> Environment: Windows XP, Visual Studio 2005, guththila, libcurl
> Reporter: Bill Mitchell
> Attachments: om_element_diff
>
>
> If axiom_element_declare_default_namespace() is called before any named
> namespace is declared, it fails to perform the axutil_hash_make and as a
> result axutil_hash_set crashes on the empty namespace pointer.
> The code fragment:
> if (om_element->namespaces)
> {
> om_element->namespaces = axutil_hash_make(env);
> if (!(om_element->namespaces))
> {
> return NULL;
> }
> }
> should read:
> if (!om_element->namespaces)
> {
> om_element->namespaces = axutil_hash_make(env);
> if (!(om_element->namespaces))
> {
> return NULL;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-927) axiom_element_declare_default_namespace fails when no namespace already declared
axiom_element_declare_default_namespace fails when no namespace already declared
Key: AXIS2C-927
URL: https://issues.apache.org/jira/browse/AXIS2C-927
Project: Axis2-C
Issue Type: Bug
Environment: Windows XP, Visual Studio 2005, guththila, libcurl
Reporter: Bill Mitchell
If axiom_element_declare_default_namespace() is called before any named
namespace is declared, it fails to perform the axutil_hash_make and as a result
axutil_hash_set crashes on the empty namespace pointer.
The code fragment:
if (om_element->namespaces)
{
om_element->namespaces = axutil_hash_make(env);
if (!(om_element->namespaces))
{
return NULL;
}
}
should read:
if (!om_element->namespaces)
{
om_element->namespaces = axutil_hash_make(env);
if (!(om_element->namespaces))
{
return NULL;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-925) seg fault in axiom_soap_fault_get_text if SOAP 1.1
[ https://issues.apache.org/jira/browse/AXIS2C-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-925: - Attachment: soapfault.diff In the attached diff, I took the quick and dirty approach of using axiom_soap_fault_text_set_base_node and axiom_soap_value_set_base_node to set the node pointer back to zero after the tree has been freed. It might be more esthetically pleasing to define some new entry points, axiom_soap_fault_value_detach_base_node, etc., that would return the old node pointer, detach the node from its parent, and clear the pointer in the fault_value or fault_text, to make it more obvious that the caller is taking ownership of the node. Or even an axiom_soap_fault_value_discard_base_node that did all the above and the axiom_node_free_tree call. But using set_base_node to set the node pointer to zero does get the job done. With the fix in the attached diff, the SOAP 1.1 fault messages from the server were handled correctly by the svc_client and stub, and the client code was able to obtain invoke axiom_soap_fault_value_get_text and the other text accessors without error. > seg fault in axiom_soap_fault_get_text if SOAP 1.1 > -- > > Key: AXIS2C-925 > URL: https://issues.apache.org/jira/browse/AXIS2C-925 > Project: Axis2-C > Issue Type: Bug > Components: xml/soap >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml2, libcurl > Reporter: Bill Mitchell > Attachments: soapfault.diff > > > If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the > client calls axiom_soap_fault_get_text. At the time of the crash, using the > debugger the om_ele_node in the fault_value points to memory that has been > reused, probably as a result of being released. When axiom_element_get_text > is called, the data_element it is passed appears to be overwritten or reused, > so axiom_element_get_text sees om_element->text_value as nonzero, tries to > free it, and the C runtime diagnoses a memory management error on the free. > Stepping through with the debugger, the crux of the problem lies in > soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the > fault_value_node, converts its contents to text, issues the free_tree to free > the node and its children, but leaves the pointer as the > axiom_soap_fault_value_base_node. So the later call to > axiom_soap_fault_get_text believes there is still a node tree structure > present. The same oversight occurs when processing the fault_reason. The > axiom_soap_fault_text_base_node is detached, converted to a single text > string, the node tree is freed, but the pointer is left as the > axiom_soap_fault_base_node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-925) seg fault in axiom_soap_fault_get_text if SOAP 1.1
seg fault in axiom_soap_fault_get_text if SOAP 1.1 -- Key: AXIS2C-925 URL: https://issues.apache.org/jira/browse/AXIS2C-925 Project: Axis2-C Issue Type: Bug Components: xml/soap Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml2, libcurl Reporter: Bill Mitchell If a SOAP 1.1 server returns a SOAP fault, a seg fault can happen if the client calls axiom_soap_fault_get_text. At the time of the crash, using the debugger the om_ele_node in the fault_value points to memory that has been reused, probably as a result of being released. When axiom_element_get_text is called, the data_element it is passed appears to be overwritten or reused, so axiom_element_get_text sees om_element->text_value as nonzero, tries to free it, and the C runtime diagnoses a memory management error on the free. Stepping through with the debugger, the crux of the problem lies in soap_body.c, where axiom_soap_body_convert_fault_to_soap11 detaches the fault_value_node, converts its contents to text, issues the free_tree to free the node and its children, but leaves the pointer as the axiom_soap_fault_value_base_node. So the later call to axiom_soap_fault_get_text believes there is still a node tree structure present. The same oversight occurs when processing the fault_reason. The axiom_soap_fault_text_base_node is detached, converted to a single text string, the node tree is freed, but the pointer is left as the axiom_soap_fault_base_node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558762#action_12558762 ] Bill Mitchell commented on AXIS2C-884: -- One reason it is difficult to isolate exactly what is happening is that WindowsXP exhibits different behavior in a multiple CPU environment than it does in a single CPU environment. In a single CPU environment, using axis2_options_set_xml_parser_reset to disable the xmlCleanupParser() call on each service termination may succeed in avoiding the libxml seg faults. This does not work in the multiple CPU environment, as seen in the crash below. This crash can happen even when only one service is created and there is no parser reset call, provided that the service is created in a "transient" thread that no longer exists when the service is freed. ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80e98b() > msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int > nBlockUse=0, const char * szFileName=0x239c, int nLine=40696612) Line > 268 + 0x15 bytesC++ msvcr80d.dll!malloc(unsigned int nSize=16809748) Line 154 + 0x15 bytes C++ libxml2.dll!xmlGetGlobalState() Line 570 C libxml2.dll!__xmlDefaultSAXHandler() Line 821 + 0x5 bytes C libxml2.dll!xmlFreeParserCtxt(_xmlParserCtxt * ctxt=0x02ac6b88) Line 1691 + 0xd bytes C libxml2.dll!xmlFreeTextReader(_xmlTextReader * reader=0x02a81898) Line 2196 + 0xc bytesC axis2_parser.dll!axis2_libxml2_reader_wrapper_free(axiom_xml_reader * parser=0x02ade048, const axutil_env * env=0x019cb498) Line 512 + 0x9 bytes C axis2_parser.dll!axiom_xml_reader_free(axiom_xml_reader * parser=0x02ade048, const axutil_env * env=0x019cb498) Line 35C axiom.dll!axiom_stax_builder_free(axiom_stax_builder * om_builder=0x02b07938, const axutil_env * env=0x019cb498) Line 885 C axiom.dll!axiom_soap_builder_free(axiom_soap_builder * soap_builder=0x02a875e8, const axutil_env * env=0x019cb498) Line 189C axiom.dll!axiom_soap_envelope_free(axiom_soap_envelope * soap_envelope=0x02a85a58, const axutil_env * env=0x019cb498) Line 168 C axis2_engine.dll!axis2_msg_ctx_free(axis2_msg_ctx * msg_ctx=0x02aa5e18, const axutil_env * env=0x019cb498) Line 374C axis2_engine.dll!axis2_op_ctx_free(axis2_op_ctx * op_ctx=0x02aea0a0, const axutil_env * env=0x019cb498) Line 165 C axis2_engine.dll!axis2_op_client_free(axis2_op_client * op_client=0x02aa3ca8, const axutil_env * env=0x019cb498) Line 615 C axis2_engine.dll!axis2_svc_client_free(axis2_svc_client * svc_client=0x019f5028, const axutil_env * env=0x019cb498) Line 1287 C axis2_engine.dll!axis2_stub_free(axis2_stub * stub=0x019cb760, const axutil_env * env=0x019cb498) Line 129 C I have not delved into the lower level Windows code to see if the thread management is doing something special in the multiple CPU case, or if this is just a race condition that appears more easily in a multi-CPU environment. Evidently, the only way to avoid the crash is to create Axis initialization and termination entry points, as suggested above, that can be called by the application in a persistent thread, or to build enough functionality into guththila that it can replace libxml. As it stands today, for the multithreaded application to avoid the crash it must perform the xmlInitParser() call to libxml2 itself when it starts up, before multithreaded processing begins, and also set_xml_parser_reset false in the options of every service client. > Seg fault in libxml when svc client torn down in a multithreaded client > --- > > Key: AXIS2C-884 > URL: https://issues.apache.org/jira/browse/AXIS2C-884 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml > 2.6.30, libcurl >Reporter: Bill Mitchell > Attachments: axis2.trace, desc_builder_diff.txt > > > In a multithreaded application, if the stub/svc client is freed in a thread > different from that used when the svc client was built, libxml crashes. The > trace below shows the information available from a release build with debug > information embedded. > I have verified this is not an effect of combining debug and release C > runtimes, or different versions of the C runtime. Rebuilding all the libxml > related dlls with the same runtime as is used
[jira] Issue Comment Edited: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556935#action_12556935 ] wtmitchell3 edited comment on AXIS2C-884 at 1/9/08 1:21 PM: -- Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I tried disabling parser_reset for all the terminations except the last. It turns out that this can still crash libxml2 in getGlobalState when issued from a thread different from the initial thread. (This is essentially the same as the traceback above when the parser cleanup was issued after each operation and the parser re-initialized for the next operation.) ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80e98b() > msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int > nBlockUse=0, const char * szFileName=0x239c, int nLine=40631000) Line > 268 + 0x15 bytesC++ msvcr80d.dll!malloc(unsigned int nSize=16744212) Line 154 + 0x15 bytes C++ libxml2.dll!xmlGetGlobalState() Line 570 C 0001() I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free, or it may appear as a standalone crash in xmlGetGlobalState with no calling information available. So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple initializations or multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset. In a true multi-threaded case, the only way for the application to be assured a way to cleanup the libxml parser is if new entry points are created so that the application can perform the initialization in a persistent thread, and not allow the parser initialization to happen in just whichever thread happens to first create a stub/svc client. was (Author: wtmitchell3): Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I have verified that one can set this option back to true on the last termination and libxml2 is not upset to be terminating in a different thread than the initial "main" thread, even when the main thread no longer exists. I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free. So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset. > Seg fault in libxml when svc client torn down in a multithreaded client > --- > > Key: AXIS2C-884 > URL: https://issues.apache.org/jira/browse/AXIS2C-884 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml > 2.6.30, libcurl >Reporter: Bill Mitchell
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556935#action_12556935 ] Bill Mitchell commented on AXIS2C-884: -- Upon re-examining the code in op_client.c, I uncovered the axis2_options_set_xml_parser_reset, which when set to false allows the application to suppress call to xmlCleanupParser on every op_client termination. So someone has obviously figured this all out before. I have verified that one can set this option back to true on the last termination and libxml2 is not upset to be terminating in a different thread than the initial "main" thread, even when the main thread no longer exists. I apologize for not figuring this out as a user error early on, but as you can see from the traces above, even with debug enabled to see where the failure happens, xmlCleanupParser is not where the crash happens, rather the crash happens in axis2_libxml2_reader_wrapper_free. So the suggestion I made above would be a source fix to ensure that users of Axis2c don't have this problem at all, but it may spend effort that would be better spent making guththila fully functional. As an alternative simple suggestion, comments could be added in reader_wrapper_free to remind the human that a crash at that point is likely caused by an earlier call to cleanup parser. As well, a simple use count would allow a reminder message to be dropped one time in the axis2.trace when cleanup is called after multiple concurrent initializations; this would likely be in the trace near the spot of the failure if the user forgot to turn off xml_parser_reset. > Seg fault in libxml when svc client torn down in a multithreaded client > --- > > Key: AXIS2C-884 > URL: https://issues.apache.org/jira/browse/AXIS2C-884 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml > 2.6.30, libcurl >Reporter: Bill Mitchell > Attachments: axis2.trace, desc_builder_diff.txt > > > In a multithreaded application, if the stub/svc client is freed in a thread > different from that used when the svc client was built, libxml crashes. The > trace below shows the information available from a release build with debug > information embedded. > I have verified this is not an effect of combining debug and release C > runtimes, or different versions of the C runtime. Rebuilding all the libxml > related dlls with the same runtime as is used for Axis and the client app > does not solve the problem. > Interestingly, rebuilding libxml with threads disabled does make the crash go > away. But the default build of libxml commonly available has native threads > enabled, and building without thread support may make the library not thread > safe. > By adding debug trace statements in the axis2.trace file, I have verified > that the xml_reader being torn down when the crash happens is the one used to > read the axis2.xml file when the configuration was first read. (axis2.trace > file attached.) > Looking at the code in libxml, it appears that libxml decides to close the > reader using an internal close routine intended for closing compressed > channels through zlib. Apparently the C runtime library returns a -1 EOF > status when closing a file opened for read. The close routine, gzio.c in > zlib, treats this as an error, and when libxml attempts to report the error > and determines that it is in a different thread, things really go downhill > fast. I have not isolated why the EnterCriticalSection call crashes in the > system, but it does. > One way to avoid the problem would be to guarantee that the stub/svc client > is freed in the same thread as created it. In my multithreaded client > application, though, I work hard to share the stub across threads > deliberately to reduce the number of distinct service clients and the > associated demand on the server. > Windows call traceback at time of crash: > ntdll.dll!7c918fea() > [Frames below may be incorrect and/or missing, no symbols loaded for > ntdll.dll] > msvcr80.dll!78134d09() > ntdll.dll!7c910e91() > ntdll.dll!7c9106eb() > msvcr80.dll!78134d83() > ntdll.dll!7c90104b() > > libxml2.dll!xmlGetGlobalState() Line 570 C > libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C > libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* > schannel=0x, void (void *, c
[jira] Created: (AXIS2C-889) misleading error message from generated stub deserialize routine when SOAP fault received
misleading error message from generated stub deserialize routine when SOAP fault received - Key: AXIS2C-889 URL: https://issues.apache.org/jira/browse/AXIS2C-889 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Priority: Trivial As you can see from the following line from the axis2.trace file, the error message when a SOAP fault message is received instead of the expected response, is misleading in that it indicates the SOAP fault was expected, and the response message was received: [Sat Jan 05 21:32:21 2008] [error] .\adb_browseResponse.c(160) Failed in building adb object for browseResponse : Expected Fault|http://schemas.xmlsoap.org/soap/envelope/|SOAP but returned browseResponse|http://frameware.xcentrisity.com/services/ In the generated code, for example in the following code, the first qname_to_string actually computes the response received, and the qname_to_string of the _browseResponse->qname indicates the expected value. AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Failed in building adb object for browseResponse : " "Expected %s but returned %s", axutil_qname_to_string(qname, env), axutil_qname_to_string(_browseResponse-> qname, env)); Inverting the last two lines to read as follows would correct this problem: AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Failed in building adb object for browseResponse : " "Expected %s but returned %s", axutil_qname_to_string(_browseResponse-> qname, env), axutil_qname_to_string(qname, env)); These lines appear to be at line 759 in CADBBeanTemplateSource.xsl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556572#action_12556572 ] Bill Mitchell commented on AXIS2C-884: -- To handle the multithreaded case, clearly the libxml2 documentation means what it says and there must be one initialize and one cleanup for the entire application. This means creating new entry points, say axis2_initialize() and axis2_cleanup, that the application client calls at the appropriate points. But demanding that all clients call these as appropriate means changing all the test cases, all the samples, all the documentation So, my suggestion is: (1) Add new entry points, axis2_initialize() and axis2_cleanup() that the client may call to manage the initialization and tear down itself. This would be required for correct multi-thread operation with libxml. (2) Add internal entry points, axis2_implicit_initialize, and axis2_implicit_cleanup, that op_client.c could use to accomplish the axiom_xml_reader_init() and cleanup. These routines would keep a use-count of active users, and, when there was no explicit initialize, would perform the underlying initialization only on the first use and the cleanup only when the last use was complete. Change (2) will fix the single-thread crash above by ensuring that no xmlCleanupParser is issued while any structures are still in use. And libxml2 seems to tolerate serial reuse as long as it is in a single thread. Change (1) gives the multithreaded client the chance to take control of the initialization and termination. > Seg fault in libxml when svc client torn down in a multithreaded client > --- > > Key: AXIS2C-884 > URL: https://issues.apache.org/jira/browse/AXIS2C-884 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml > 2.6.30, libcurl >Reporter: Bill Mitchell > Attachments: axis2.trace, desc_builder_diff.txt > > > In a multithreaded application, if the stub/svc client is freed in a thread > different from that used when the svc client was built, libxml crashes. The > trace below shows the information available from a release build with debug > information embedded. > I have verified this is not an effect of combining debug and release C > runtimes, or different versions of the C runtime. Rebuilding all the libxml > related dlls with the same runtime as is used for Axis and the client app > does not solve the problem. > Interestingly, rebuilding libxml with threads disabled does make the crash go > away. But the default build of libxml commonly available has native threads > enabled, and building without thread support may make the library not thread > safe. > By adding debug trace statements in the axis2.trace file, I have verified > that the xml_reader being torn down when the crash happens is the one used to > read the axis2.xml file when the configuration was first read. (axis2.trace > file attached.) > Looking at the code in libxml, it appears that libxml decides to close the > reader using an internal close routine intended for closing compressed > channels through zlib. Apparently the C runtime library returns a -1 EOF > status when closing a file opened for read. The close routine, gzio.c in > zlib, treats this as an error, and when libxml attempts to report the error > and determines that it is in a different thread, things really go downhill > fast. I have not isolated why the EnterCriticalSection call crashes in the > system, but it does. > One way to avoid the problem would be to guarantee that the stub/svc client > is freed in the same thread as created it. In my multithreaded client > application, though, I work hard to share the stub across threads > deliberately to reduce the number of distinct service clients and the > associated demand on the server. > Windows call traceback at time of crash: > ntdll.dll!7c918fea() > [Frames below may be incorrect and/or missing, no symbols loaded for > ntdll.dll] > msvcr80.dll!78134d09() > ntdll.dll!7c910e91() > ntdll.dll!7c9106eb() > msvcr80.dll!78134d83() > ntdll.dll!7c90104b() > > libxml2.dll!xmlGetGlobalState() Line 570 C > libxml2.dll!__xmlLastError() Line 709 + 0x5 bytes C > libxml2.dll!__xmlRaiseError(void (void *, _xmlError *)* > schannel=0x, void (void *, const char *, )* > channel=0x, void * data=0x0
[jira] Commented: (AXIS2C-884) Seg fault in libxml when svc client torn down in a multithreaded client
[ https://issues.apache.org/jira/browse/AXIS2C-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556569#action_12556569 ] Bill Mitchell commented on AXIS2C-884: -- To isolate what kind of fix might work for the multithreading case, for testing I commented out the xmlInitParser() and xmlCleanupParser() calls and moved these into the application threads. If these calls are issued once at the start of the application and once at the end, all works well. The same is not true when attempting to use libxml2 serially in multiple threads. In particular, I tried creating and freeing the stub around each SOAP message, and performing an xmlInitParser and xmlCleanupParser around each use. Even in the application where mutex's can ensure that the xmlCleanupParser() completes before an xmlInitParser() is issued, and the use_counts are maintained under mutex to avoid race conditions, the first time libxml2 is initialized in a second thread after being freed in the first thread, the crash in xmlGetGlobalState reappears. See the traceback below, as well as relevant trace lines from my application trace. ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] kernel32.dll!7c80e98b() > msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=12, int nhFlag=0, int > nBlockUse=0, const char * szFileName=0x2220, int nLine=67225284) Line > 268 + 0x15 bytesC++ msvcr80d.dll!malloc(unsigned int nSize=17792788) Line 154 + 0x15 bytes C++ libxml2.dll!xmlGetGlobalState() Line 570 C [EMAIL PROTECTED]: | | | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Freeing libxml2 [EMAIL PROTECTED]: | | | | | | | | info: Initializing libxml2 > Seg fault in libxml when svc client torn down in a multithreaded client > --- > > Key: AXIS2C-884 > URL: https://issues.apache.org/jira/browse/AXIS2C-884 > Project: Axis2-C > Issue Type: Bug > Components: core/deployment >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml 2.6.25 and libxml > 2.6.30, libcurl >Reporter: Bill Mitchell > Attachments: axis2.trace, desc_builder_diff.txt > > > In a multithreaded application, if the stub/svc client is freed in a thread > different from that used when the svc client was built, libxml crashes. The > trace below shows the information available from a release build with debug > information embedded. > I have verified this is not an effect of combining debug and release C > runtimes, or different versions of the C runtime. Rebuilding all the libxml > related dlls with the same runtime as is used for Axis and the client app > does not solve the problem. > Interestingly, rebuilding libxml with threads disabled does make the crash go > away. But the default build of libxml commonly available has native threads > enabled, and building without thread support may make the library not thread > safe. > By adding debug trace statements in the axis2.trace file, I have verified > that the xml_reader being torn down when the crash happens is the one used to > read the axis2.xml file when the configuration was first read. (axis2.trace > file attached.) > Looking at the code in libxml, it appears that libxml decides to close the > reader using an internal close routine intended for closing compressed > channels through zlib. Apparently the C runtime library returns a -1 EOF > status when closing a file opened for read. The close routine, gzio.c in > zlib, treats this as an error, and when libxml attempts to report the error > and determines that it is in a different thread, things really go downhill > fast. I have not isolated why the EnterCriticalSection call crashes in the > system, but it
