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”
Maybe as a start, OpenAdaptor 3 should focus firstly on creating nice JBI components that can drop into a JBI stack like ServiceMix (http://servicemix.org). 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) 🙂
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 🙂
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.
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.
Got us bang to rights! Although we have far more complaints than you do.
oa is 6-7 years old and is creaking mightily – hence oa3. Don’t want to be dependent on container technologies as I think they’re overblown. But we will play nicely with containers.
Want to contribute ideas to oa3? Please do! http://openadaptor.openadaptor.org/servlets/ForumMessageList?forumID=5, or, pop down and have a chat.