Hi Thanks for the detailed feedback. Some commets inlined.
On Thu, Aug 7, 2014 at 12:46 PM, falcopaul <[email protected]> wrote: > Hi. > > I have just completed a considerable Camel project and want to feedback some > of my experiences to the developer team. Please note that I am an > experienced developer with many years of Java background. Also note that I > have used most of Camel from a Spring XML context. As many other developers > I have struggled with the library, although I was able to find solutions for > many problems in the end. This post is to highlight some of these issues. > > Overall, I think Camel is a very strong offering, but there is a very steep > learning curve. I often felt like simply coding the integration logic myself > and giving up on Camel. Looking back, I spend too much time on figuring out > how to resolve relatively easy use cases. > > May new users will start with the File component. Part of the problem here > is the ‘polling’ mechanism that the File component does. I believe it would > be good if there is also a non polling variant for the File component. Many > use cases do not require polling at all. As a new starting user, you end up > with code that doesn’t seem to exit from the Main method due to the polling > (which is somewhat confusing). The docs should clarify that more, but I > think a non polling option for the File component is a better solution IMHO. > A good place to start is the EIP which is the building blocks and concepts Apache Camel was created and practices. http://camel.apache.org/eip So the idea with the routes and components is that they are "messaging based" so in case of files, they react when a new file "arrives". But it sounds like you may are using the wrong solution for your use case. Apache Camel is not really meant for short lived one-time tasks, where you check if X files are in a dir, and do Y, and then stop etc. Which is what I sense you are have been struggled with. eg Camel is not a replacement for batch scripts / perl scripts or whatever hacks / scripts people are doing for moving files between their systems. > While nagging about polling components I have also found that the > ‘sendEmptyMessage’ is (IMHO) a bit of a hack. I would like to see a more Apache Camel 2.0 did not include that option to start with. It was an option from 1.x days of Camel. But we introduced it again in 2.x as some end users wanted it back. > integrated approach so that it would be possible to work with constructs > such as <onIdle> or <onNoBatchInput>. The current solution is making the > routes look unnecessary cluttered: > <choice> > <when> > <spel>#{request.body == null}</spel> > <process ref="shutdownRouting"/> > </when> > <otherwise> > </otherwise> > </choice> > There is plenty of other ways which you may not have found such as route policy, where you can control lifecycle of routes outside the DSL. So you can automatic shutdown the routes if its idle for X period etc. > Too much boilerplate for my liking… > > Also, I found (and find) that it is really weird that the current > implementation for the File component does not allow dynamic directories. > Again, it’s hackable, i.e. by using a ‘trick’ such as “<from > uri="file:{{dir.input}}”, but one simply expects as a new user that > {$dir.input} should work. I know it is also resolvable by using > <endpoint> tags, but it all takes too much time to figure these things > out as a starting Camel user. > The file component requires a starting directory. That is the dir you configure. Whether its hardcoded or uses placeholders. Then you can use filter / ant filter pattern and much more to filter dirs / files to be included / excluded. And you can also implemented that logic from java code to have full control and dynamism. > The conflicts between Spring ${} and Camel ${} are also slightly awkward, > although it is all documented somewhere. It would also be really nice if > Spring bean injection would be more natural in terms of syntax. > You are barking up the wrong tree. Its the spring guys that don't care. We have logged a JIRA ticket for 6+ years See this FAQ http://camel.apache.org/how-do-i-use-spring-property-placeholder-with-camel-xml.html And the JIRA http://jira.springframework.org/browse/SPR-4466 Its however fairly easy as Camel uses {{ }} and Spring ${ }. But you can reconfigure the Camel syntax if you want. Though where you may be confused is the Camel simple language which also uses ${ } for its functions. But we have $simple{ } as an alternative style that can be used in case Spring "is in the way". Or for people using groovy where groovy may interpolate strings using ${ } style as well. > Another shortcoming (in my view) is the lack of build-in support for easy > stopping/starting of (other) routes and camel contexts. Yes, I can code my > own class to do these things, but WHY? There are many documentation > references to sample code for this, so why not simply include it in the base > package? It is such a common use case! > A good idea is to learn a bit about the EIP patterns. There is the control bus pattern http://camel.apache.org/controlbus And there is also this FAQ http://camel.apache.org/how-can-i-stop-a-route-from-a-route.html You can control routes in many ways: java api / jmx / controlbus component / route policy / Camel's event notifier etc. And if you use Apache Karaf / ServiceMix / fabric8 as the container then there is also camel commands you can use to control routes from its shell. And the the shell can be scripted and called from platform scripts / REST and whatnot. > While talking about inter-route communication I like to mention the > NotifyBuilder. It is really powerful and it should (in my view) be more > strongly integrated, so the concepts will be usable from the DSL/Spring XML. > It would allow an easy implementation for many complicated routings and > inter-route communication/signaling. NotifyBuilder is also hidden very deep > in the documentation, which is a shame. > Its documented in the testing documentation http://camel.apache.org/testing Though I suggest to pickup any of the Camel books if you want to get more serious with Camel. Any of them will get you on a better start than using only the online wiki documentation. That documentation is not well suited reading as a comprehensive book will do. Also there is a lot more effort put into authoring those books, than the wiki docs. The wiki is for reference. Frankly I personally pickup books for projects I get serious about. If my employer pays a high salary for me. The best value for money I can do is to pay $30-40 for a book and read a couple of hours to get better suited. > Another nag I want to bring forward is the “Enrich” integration pattern. A > very common use case, but the Camel components for the enrich pattern are so > complicated that I never ended up using it (using <process> instead). > Maybe get in touch sooner. What is so complicated? We are not aware that people are having trouble with that pattern. Its usually more about scatter/gatter/aggregator/or error handling etc. > Finally, it would be good if there is easy access to route statistics > (message delivered, etc). If for example the Simple language would have this > than certain routing logic would become relatively easy to implement. You can get route stat easily from JMX MBeans, or there is also the camel-jmx component. Also the control-bus component can give stats also. Though we could have a language or new function on simple to gather X stats as well. Can you tell more about your use case, and how you would envision to do that in Camel if simple could do it? Maybe a pseudo code example? > To conclude: I really like Camel, but it can be so much stronger if some of > the above issues can be addressed. > Thanks. Though it seem you got in touch with the community to late. Or could have been better off picking up a boo.. > Please don’t take my critics too negative, but I do feel that people with > complicated use cases may give up on Camel due to some of the above > mentioned points. That would be a shame as the framework is of high > engineering quality. > > Regards, > Falco > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Library-usage-improvement-suggestions-tp5754892.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
