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