Just my 2 cents... I tend to focus more on Camel as a library and much less on it as an EIP engine or runtime. I think things get "over-EIP'ed" many times.
In general I just try and keep routes as short as humanly possible, as asynchronous as possible and as distributable as possible. Whenever I hear toolbox I tend to think constraints, one of the things I really like about Camel is that there isn't a forced / enforced way of solving problems. -- That quickly brings JBI to mind :) Or how competing frameworks talks about channels, deployment models controlling what to do or how to construct xml descriptors.... On Jul 11, 2013, at 5:59 PM, Raul Kripalani <r...@evosent.com> wrote: > Hi guys, > > For a few months I've been wanting to build a set of utility classes with > the goal of providing a "toolbox" for commonly used AggregationStrategies, > OnPrepare processors, debug processors, etc. > > Basically to make life easier for everyone. I feel there's too much > repeating that users can avoid if we provide certain basic uses cases out > of the box. > > Moreover, newcomers find it hard to fully understand the role of properties > and headers for data pipelining inside routes. This toolbox can help settle > the concepts in common EIP scenarios. > > So feel free to contribute your thoughts and ideas on > https://issues.apache.org/jira/browse/CAMEL-6542. > > What pieces of logic do you tend to repeat across projects? What do you > carry in your Camel "toolbox" that other users may benefit from? > > Thanks, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk
