Apache XML-RPC Hand Wringing

It seems like those that are actually bothering to write about Java programming are framework crazy, in one of two distinct ways.

The first group, of which I have occasionally been a member, are all about building new tools, frameworks, and libraries, regardless of whether perfectly usable examples may already exist. To be fair, in some cases, this sort of competition is healthy. In other cases, though, its just wasteful and confusing.

The other group, though, which I have ranted about in the past on my podcast, want frameworks, libraries and tools to do every little last thing for them. By the content of this article, this O’Reilly blogger places himself firmly in the second camp.

Ordinarily, I’d just ignore a post like this, except that I, myself, have also been working with Apache’s XML-RPC library, version 3.0, this week.

I don’t have any legacy code, but have certainly gone through the pain involved in the kind of migration he is contemplating. Especially with the refactoring tool support currently available such effort is pretty limited. I shudder to imagine the size and/or complexity of his code base that would leave him reluctant to spend a half day just grinning and bearing it.

His complaint about having to run the library’s web server is just out and out wrong. They do provide one extension point that allows you to run in the web container of your choice. Personally, I’d prefer a bit more flexibility than extending their servlet, but it wasn’t that big a deal for my needs. I wrote my application specific code where needed, mostly for application authentication and called through the super reference into their automagic code.

Is it me, or have all the Spring and IoC advocates forgotten how to write glue code? He doesn’t like the built in support for just instantiating his handlers, without handing them some sort of configuration hook or execution context. Fine, but I solved that problem for my project in less than an hour, and I don’t even have any fancy-schmancy IoC container. My handler mapping implementation is all of ten lines of code. My application boot strap code grew by maybe another twenty lines, if that, to reflect over a list of service interfaces in my application and use a custom annotation I rolled my sleeves up and wrote to build all the context my handlers need.

As for his wish list, um, how about writing up a module for Spring himself that bridges the two systems and either contributing it to Spring or setting up a new project for it on one of the many free project sites? I wrote code that does just about everything he wants, except for integrating with Spring, in about a day. I totally disagree, the 3.0 library is pretty darn close to little more than a simple implementation of the specification. My only complaint, as mentioned, is the limited options for extension, but otherwise, I think it does the job nicely and frees me up to concentrate on concerns more specific to my application.

Leave a Reply

Your email address will not be published. Required fields are marked *