A few months ago, I had researched using Axis2/C 1.1 as a client-side API (specifically, to use Microsoft's Exchange 2007 web services). However, due to a few bugs, some limitations, and unneeded complexity, I abandoned it and switched to writing and parsing the SOAP envelopes myself, and using libcurl for the HTTP functionality. Since I saw that 1.2 was released, I decided to take a look to see if the bugs I found were fixed. Since libcurl serves my needs I don't really have any motivation to try Axis2/C again, but I thought I would still report two bugs for the community's sake.
The first bug I noticed is in http_sender.c, I was experiencing a crash in axis2_http_sender_configure_http_basic_auth(). I haven't tested it in Axis2/C 1.2, but it looks like the same bug is still there. int plen = axutil_strlen (uname) + axutil_strlen (passwd) + 1; ... sprintf (to_encode, "%s:%s", uname, passwd); The to_encode buffer is one character short. Someone either forgot to include room for the colon, or the terminating null. The simple fix is to replace "+ 1" with "+ 2". The second bug I noticed is in axis2_libcurl.c, there are three lines that say: char tmp_buf[10]; sprintf (tmp_buf, "%d", buffer_size); headers = curl_slist_append (headers, axutil_stracat (env, content_len, tmp_buf)); I had to comment these out. Libcurl will determine the Content-Length itself based on the data you pass to curl_easy_opt(handler, CURLOPT_WRITEDATA, data). While explicitly specifying the Content-Length is not a problem (though completely unnecessary) with no authentication or basic authentication, it causes a problem with authentication mechanisms that require challenge/response (such as NTLM). The Content-Length for the challenge will specify a non-zero Content-Length, but the HTTP body will be empty. With IIS at least, this results in a HTTP error 400 (Bad Request). I can send a Wireshark network capture (or screenshots) if anyone wants to see what I'm talking about. While these are the only two bugs that I noticed might need fixing, I suppose someone might ask what the other bugs, limitations, and unnecessary complexities were. Here are some of them in case you are wondering: 1. The WSDL codegen (from Axis2/Java 1.3) was generating invalid C code with Microsoft's WSDL. It was trivial to fix with a couple search and replaces though. I was using the publicly released version (and not nightly build), so maybe it has improved. 2. When using Axis2/C with libcurl, there is no way to specify any of the libcurl parameters such as authentication username/password, or any of the SSL parameters. I had to hard-code things in axis2_libcurl_send(), such as CURLOPT_HTTPAUTH, CURLOPT_USERPWD, and CURLOPT_CAPATH. Again, it is trivial to fix, but it would be nice if there was some way to pass arbitrary libcurl parameters through axis2_options_set_property(). 3. As far as unneeded complexity, it didn't seem in my case that Axis2/C was really adding a lot of functionality. I have the impression that Axis2/C would be much more useful if I was writing a web service (server) than when writing a consumer of a web service (client), since the former is typically a lot more complex. Considering that I was having to parse the XML myself anyway in the SOAP responses (unlike SOAP APIs like .NETs and perhaps AxisC++, where you are given nice classes that represent XML nodes, and class member variables for the XML attributes and text), it seemed about the only thing that Axis2/C was adding for me was not having to formulate the SOAP requests myself and instead just call a codegen'ed stub function. But then #1 and #4 (below) eliminated even that advantage. Also, as far as install, Axis2/C requires a lot of files in a directory structure, an axis2.xml file, AXIS2_HOME environment variable, etc., whereas libcurl requires a single file at that's it. 4. The "breaking point" for me was that the stub functions weren't allowing me to specify certain information in the <soap:header>. For example, Exchange Web Services uses SOAP headers to pass in an XML element called <ExchangeImpersonation>, which provides a proxy authorization mechanism. In other words, you authenticate through HTTP as an admin user, but then specify the user's mailbox you wish to access with the <ExchangeImpersonation> node in the SOAP header. The codegen'ed stub provided a parameter for this node (and other optional nodes in the header), but it doesn't do anything with it. Again, maybe this is something that will improve with a more recent version of Axis2/Java. Please don't construe any of this as criticism of Axis2/C in general. I can certainly see great benefit it provides. I just wanted to provide the bug reports and how it didn't suit my particular situation. Greg Moriarty --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
