camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From falcopaul <falco.p...@gmail.com>
Subject Library usage improvement suggestions
Date Thu, 07 Aug 2014 10:46:54 GMT
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.

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
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>

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=&quot;file:{{dir.input}}”, but one simply expects as a new user that
{$dir.input} should work. I know it is also resolvable by using
&lt;endpoint> tags, but it all takes too much time to figure these things
out as a starting Camel user. 

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.

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! 

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. 

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). 

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.
To conclude: I really like Camel, but it can be so much stronger if some of
the above issues can be addressed. 

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.

Mime
View raw message