camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McNerney <>
Subject Re: Is camel the right choice for me?
Date Wed, 09 Dec 2009 03:59:29 GMT
I'm a very new user of Camel, so take that for what it is worth. I
started off using Mule and became disenchanted by it very quickly
(especially when trying to troubleshoot an issue I had with it). It
felt like overkill for what I needed. I was quite pleased by my
attempts with a few test cases in Camel. It was cleaner, more
lightweight and really felt like it was working with me, rather than
trying to push me into its idioms. I've been very happy with it so

Let me throw in one other *huge* plus for using Camel. I have rarely
worked with a more helpful community than the Camel folks. Claus and
Willem and Charles have been hugely helpful for me and I'm pretty sure
they are not real people, but teams of developers answering questions
24/7/364 (they can have New Year's Day off). I'm feeling very
comfortable with my choice to use Camel.

To your specific issues, I'll let Clauemles answer.


On Tue, Dec 8, 2009 at 6:22 PM, pangea <> wrote:
> Helo all -
> we have a home grown communication framework (based on other open source
> components like apache commons, axis etc) that we have been using so far. It
> works great but
> - It has many limitations like no connection pooling,
> - only supports tcp/ip, http(s), soap (Axis 1.4 only), and JDBC (hibernate
> 2.1.8)
> - we doesnt want to maintain it anymore
> I am looking into replacing it with open source framework. I like the DSL
> based approach of Camel and seems like its lightweight unlike Mule and
> others. Appreciate if someone can let me know if camel supports the below
> usecases. Thank you in advance
> 1) I should be able to configure/set all the protocol level properties (for
> e.g. in case of http custom headers, keep-alive, GET or POST etc, for tcp-ip
> - so_linger etc) thru configuration and also runtime from code.
> 2) Ability to pool the connections
> 3) Ability to configure multiple URLs for a given endpoint. Our partners
> expose multiple URLs each for DEV, TEST, QA, PROD etc. Idea is to configure
> all the URLs for these different regions during development and choose which
> one to use while deployment.
> 4) Ability to expose all the protocol aspects so that we can modify if
> required
> 5) Support for REST
> 6) Support for SOAP (ability to choose Axis or CXF or others)
> 7) Proxy configuration, NTLM auth for HTTP
> 8) Re-try strategies
> 9) Performant
> 1) Support for polling
> 2) Client certs (keystore) support
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

View raw message