Lately I have been quite busy working on Apache Camel. We are about to finalize on a new release 1.4. I am happy to report that I managed to solve an issue in Camel related to WebSpheres dreadful classloading issues.
As Camel isn't a new pet in town and the community hasn't reported the issue before its a sign in the moon and wind that the fantastic open source community isn't riding on IBM's heavy elephant anymore - count yourself lucky for that!
Well as starting and stopping WebSphere isn't a fun activity to do in my spare time I had other issues to look and solve, such as many of the end-user request, patches and feature suggestions - keep 'em coming.
So finally I found some quite time and started tackle the beast. In the end it was all coming down to the fact that WebSphere classloader wasn't able to load a packagename from a URL resource. You must provide some kind of file resource such as a .class file. And as Camel is a clever framework that can auto register its type converters from just providing packagenames it should recursive scan the solutions wasn't to easy as end-users can also use this feature and provide their own packagenames to scan.
However at the end we have a workaround in Camel 1.4 to let it be able to run on the IBM elephant.