Sam Newman's site, a Consultant at ThoughtWorks

It’s been a while since I’ve had to unleash the angry kitten, but it seems that the OpenAdaptor developers have rather inadvisably irked me, to the extent that I’ve withheld the kitten’s food for two days now, to make the ensuing carnage all the more…well, carnagy.

To start with, I like the concept and some of the architecure behind Open Adaptor. It’s a fine arhictecture – it’s no suprise that plenty of other APIs out there have come up with similar solutions to the same problems. The JBI spec obviously owes a lot to OpenAdaptor. That said its implementation frequently makes me want to have a few minutes with the developers, a pair of pliers and a blowtorch.

Creating sinks, pipes and sources

Let’s start with the fact that to create anything you’re pratically forced to use property files. No Inversion Of Control for you my son, oh no – here we have a special init method, which is not a constructor because…well, it’s called init, its enforced by the API, and it takes a Properties object. The only benifit over being able to construct objects the way you want seems to be it made it easy for the developers to use property files (I hope for the next version they at least look at spring). That makes tesing so much fun. Please note the sarcasm.

JARs not built using debug information

Yes, you heard me right. Here was I, thinking we lived in the age of high-speed internet connections. But in fact it seems internet bandwidth is so tight that the developers considered providing debug information so we could work out for which odd reason an Adaptor fails a luxury.

Errors that are not errors – or might be

So when your adaptor fails with no clear reason why – well, what should you do? That’s right, turn on debug – chances are a debug message will detail why your adaptor failed. Even better, sometimes the error message will be vague, for example the one that tells me that either my JNDI server may be unavailable, or that it is there but the thing I want isn’t, or that it is there and the thing I want is there, only I might be missing a class, only it won’t tell me what class that might be. That is an error message that can be really fun to work with. And I don’t mean the good type of fun either, I mean the achingly irritating kind of fun that can only result in me hurting my foot kicking office furniture.

A nice idea crippled by an allergy to interfaces

OpenAdaptor has a rather sensible and useful (sounding) feature called message hospitals. Normally, if a message causes an exception the app shuts down. You can however choose to configure a message hospital which will capture all messages which throw an exception – but only an exception of a given type. However by “type” OpenAdaptor means “class” – you have to throw a checked PipelineException. This is bad enough – I now have to have a top-level catch throwable clause that rethrows PipelineException – but the constructor doesn’t even take a root cause. Quite why a simple ExceptionType interface couldn’t be used I have no idea.


OpenAdaptor has a sound premise, but it’s implementation needs bringing up to date. A full rewrite in the form of OpenAdaptor 3 is underway – get involved.

5 Responses to “OpenAdaptor, boiling lead and the angry kitten”

  1. James Strachan

    Maybe as a start, OpenAdaptor 3 should focus firstly on creating nice JBI components that can drop into a JBI stack like ServiceMix ( Then they don’t have to worry about learning all about Spring, dependency injection, handling faults properly, error handling and building a proper modern container with JCA support etc.

    Then when they’ve done that and experimented with ServiceMix, they might find they’ve learnt a few things they can use if they still wanna make a container – or hopefully they might just realise an open source JBI container is probably the best platform for OpenAdaptor to build on – then they can focus on what they do best, integration components, and not worry too much about designing a new API (just use JBI) or a container (just use ServiceMix) 🙂

  2. Sam Newman

    I have cause to talk to the OpenAdaptor guys every now and then so I’ll be sure to pass that on – mind you I’m sure you must bump into them every now and then James 🙂

  3. Carlos E. Perez

    I agree with James comment that the OpenAdaptor guys should consider “adapting” their sources and sinks to play inside a JBI container like ServiceMix. I had initial thoughts of doing that work, but if they’re up to that task, then I could then focus on other more pressing matters.


  4. Sam Newman

    I’ll speak to them, but most of the development is being done by Dresdner itself (the original authors) and their focus is for internal requirements. I’m hopeful that if enough people voice their desires for the new OA3 that you can still influence the design, because as it stands I would not choose to use OpenAdaptor if I wasn’t forced to by my current project.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: