The Mind Electric’s Glue loses a user

David Watson has just made the switch from Glue to Apache Axis. I understand his pain, as everything broke on my server when I “upgraded” Glue from 2.x to 3.2. However, I managed to get it working although I was not deploying my application in a JAR, but rather a WAR, so that might have made a difference. For the record, here is what I did:

  1. Placed Glue’s config.xml in /WEB-INF/classes/electric/common/WEB-INF/
  2. Placed the standard.map file in /WEB-INF/classes/electric/common/WEB-INF/maps/
  3. Placed GLUE-STD.jar in /WEB-INF/libs/

After that, no more errors.

David makes a rather interesting statement in his entry which I’d like to comment on:

“Deployment descriptors are overrated, especially when the code can reflect a lot of the details at runtime. If I need to set parameters, I’ll do it in the code, thanks.”

As someone who has had to garner information about parameter and return types from a client’s WSDL document, I can honestly say that deployment descriptor files are certainly not overrated. Had the client we were dealing with created a proper WSDL file, I wouldn’t have had to bother them incessently with questions as to what structure the request parameters and responses took. As it turns out, some of the request and response parameters were string representations of XML documents, easily replaced with custom type declarations within the WSDL. Indeed, some of the responses were documented as arrays of “any”, which is the WSDL world equivalent of Object or void. Had the client not even provided any WSDL information and instead had the parameters hardcoded in source, as David would prefer, it would have been a nightmare, and not just an annoyance.

Don’t get me wrong, I dislike SOAP as it is heavyweight and cumbersome, but if you’re going to use it, at least use it as it was meant to be used.