+1 for providing some utility DSL or method to enhance the usage of Camel. Split and Aggregate are the common EIP We may use every day.
I think we can add some utility for the Split at same time. -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Friday, July 12, 2013 at 9:04 AM, Raul Kripalani wrote: > Hey Johan, > > Thanks for the quick feedback! I agree with you – the goal is not to > enforce particular ways of solving problems, but rather to provide > shortcuts to commonly used tactics, even for short-lived > interactions/mediations built on Camel. > > Just to give a concrete example, I find myself repeating things like these > over and over again: > - storing the output of an enrichment in a property > - multicasting to a number of endpoints and filtering all responses, > keeping only the ones that satisfy a given condition > - storing the result body of a split in a List (not a List<Exchange> like > the GroupedExchangeAggregationStrategy offers) > - ... > > So I'd like to offer these pieces of logic in built-in utility classes, > such that users can do things like these elegantly: > > from(abc) > .to(def) > .enrich(xyz, AggregationStrategies.storeInProperty("MyCamelProperty")) > .log(...); > > or: > > import static o.a.c.t.AggregationStrategies.*; > > from(abc) > .split(body().tokenize(","), > storeInList(keepOnly(xpath("/result = 'ok'"))) > .to("http:...") > .end(); > > Maybe it's calling this a "toolbox" is an overelaborate term (maybe it's a > DSL or fluent builder for Aggregation strategies). But I like the idea of > everyone contributing reusable bits and pieces to build up a communal > toolbox. > > Check out https://issues.apache.org/jira/browse/CAMEL-6542 for a few > utility methods that sprang to mind. > > Regards, > > *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 > > On Fri, Jul 12, 2013 at 1:21 AM, Johan Edstrom <seij...@gmail.com > (mailto:seij...@gmail.com)> wrote: > > > 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 > > (mailto: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 > > >
