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.
Subscribe to:
Post Comments (Atom)
2 comments:
That is great. Have you (or anyone) tried to get it to work with SI Bus (the default messaging provider). Experience/Feedback?
Referring to SI Bus do you mean the build in JMS Broker in the WebSphere Application Server?
If so yes at the time we developed prototypes using Camel and WebSphere App Server which used the build in JMS broker for local queues. And we also did some prototypes using a remote WebSphereMQ Broker.
Post a Comment