axis2: the sequel reeks

(outpourings biased by a series of unfortunate events)

I recently returned to the natatorium of web services with the most variations of alphabet soup, the most fertile bed of specifications, some unfortunate acronyms (it's the time to DISCO ... get yourself some ROPE ... and who can forget SOAP?) and enough layers around an old idea to make it look like an adorned overfed pachyderm. The tools seemed to have improved; or perhaps they had just grown to have stronger armour to withstand the onslaught of specifications and protocols. Axis, the most popular open-source toolkit for web services had made way for Axis2. Axis2, it turned out, had decided to try and beat the WS soup nazis at their own game. It came up with its own complex design (ADB, AARs) and its own alphabet soup (an object model called AXIOM).

Getting started was not a problem, but once you started using the beast, you began to see the cracks. A simple client needed 18 JARs and notched a footprint of several megabytes. You saw all the typos (When users sends SOAP messages) and poor grammar (User care able to set his own mime-boundary string using this property) in supporting articles and in the documentation (Substract?). You also saw how careless the documentation was at times (the supporting text files for the 1.5.1 distribution contain URLs for the 1.4 distribution). You were taken aback at how incomplete (why have two articles on configuration parameters, when you could have just added some more javadoc? Then there was lack of support for enums, which is unfortunate because you just lost a clean strong way to enforce some constraints on parameter values. It's also a bit silly since J2SE 1.5 is the JDK of choice and the support for enums represented one of the most useful things that came with that version. If you wanted to try using minOccurs or maxOccurs, you were out of luck again. It all started looking like a giant step back for WS-kind.

Let's not even get started on interoperability or support for Spring. There's a very limited view of the world as far that last thing is concerned and it's a gross violation of the larger view that the developers of Spring have adopted. It's time to look at something simpler and more useful. After all, getting an elephant to guard your house soon becomes an economic problem (there's also the pachydump to consider).

(a few hours later). Oh great! Despite tall claims, Axis2 has severe problems with basic inheritance.

(a few days later). I am of the opinion that the quality of logging in any project says a lot about the quality of the project itself. This makes Axis2 suck even more. Let's start with org.apache.axis2.context.AbstractContext and scroll down to the method debugPropertySet(String key, Object value). The following block of code contains enough to send your lunch back up your throat:

log.debug("==================");
log.debug(" Property set on object " + identity);
log.debug("  Key =" + key);
if (valueText != null) {
    log.debug("  Value =" + valueText);
}
log.debug("  Value Class = " + className);
log.debug("  Value Classloader = " + classloader);
log.debug(  "Call Stack = " + JavaUtils.callStackToString());
log.debug("==================");

What a great place to practise your minimal competence in ASCII art. The fun doesn't end here. Let us turn our attention to org.apache.axis2.util.JavaUtils and specifically to the method callStackToString.

/**
 * Get a string containing the stack of the current location.
 * Note This utility is useful in debug scenarios to dump out 
 * the call stack.
 *
 * @return String
 */
public static String callStackToString() {
    return stackToString(new RuntimeException());
}

/**
 * Get a string containing the stack of the specified exception
 *
 * @param e
 * @return
 */
public static String stackToString(Throwable e) {
    java.io.StringWriter sw = new java.io.StringWriter();
    java.io.BufferedWriter bw = new java.io.BufferedWriter(sw);
    java.io.PrintWriter pw = new java.io.PrintWriter(bw);
    e.printStackTrace(pw);
    pw.close();
    String text = sw.getBuffer().toString();
    // Jump past the throwable
    text = text.substring(text.indexOf("at"));
    text = replace(text, "at ", "DEBUG_FRAME = ");
    return text;
}

Turn up the logging for org.apache.axis2 to see what I mean. Your log file will start looking like Armageddon and none of the traces will offer any useful information. The lack of respect for both performance and the usefulness of information is, however, appalling.

[march 23, 2010]: I should have just seen if Hani Suleiman had anything to say about Axis2. Guess what? He already said his piece in 2006. It's all there in the bile. If only I had read this first: I agree about the documentation, the language, the quality of code (System.out.println calls instead of logging calls; a complete lack of logging in core code, which means that I have exactly no idea what's going on behind the scenes even with the Axis2 code in front of me). Heck! I agree about everything. I wonder how the ASF let such a sub-par project into its fold. I leave you with a sample log message (some details have been removed in the interests of privacy) from the morass of one of the numerous builders floating in the source tree: Build the OMElelment obfuscatedFieldNameBy the StaxSOAPModelBuilder