camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <r...@evosent.com>
Subject Re: Camel toolbox for frequently used pieces of logic
Date Fri, 12 Jul 2013 01:04:08 GMT
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 <seijoed@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 <raul@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message