Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of kraythe@gmail.com designates
 209.85.220.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJtt6BgPhX-4OOjVAFLqsqymPhWxfFBP+yNeygyy8GTr==k2yQ@mail.gmail.com>
References: 
 <CAGfr3_nBebTir4qPY2L39dTeiZyeKoxecHHA0-H6L9mFRpR2gg@mail.gmail.com>
	<CA+2r3Z71WSt0LxuXC_j49=OhMYamZ0UrPTqqRriHU7xp09yKNw@mail.gmail.com>
	<CAGB5yN=vw4+jQGxb6wCayDwna_Gkh5xMjsWG-ibwVLHYYeQ6zg@mail.gmail.com>
	<CAJtt6BgPhX-4OOjVAFLqsqymPhWxfFBP+yNeygyy8GTr==k2yQ@mail.gmail.com>
Date: Thu, 5 Jun 2014 12:54:14 -0500
Message-ID: 
 <CAGfr3_=EW1HudDK00Q_ouZa0RiKyPQm5=sUBAKh3qD55FTdtGg@mail.gmail.com>
Subject: Re: Missing Important Use Case in Camel - Enrich current exchange
 using Consumer
From: "kraythe ." <kraythe@gmail.com>
To: Camel Users List <users@camel.apache.org>
Content-Type: multipart/alternative; boundary=047d7bd6b87ce400d804fb1a6eb8

--047d7bd6b87ce400d804fb1a6eb8
Content-Type: text/plain; charset=UTF-8

Actually I don't think the semantics need to change with the exception of
enhancing the enrich EIP to include a synchronous on demand pull. You have
enrich and pollEnrich and what we need is consumeEnrich. Then if the
components support the activity (which should use nearly the same identical
code) it should all be magic.

I don't think there is a fundamental issue here and a small change could
fix the functionality gap.

*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*


On Thu, Jun 5, 2014 at 9:21 AM, Camel Guy <camel@devguy.com> wrote:

> When I first started using Camel, I thought it was strange that the mongodb
> component returned data via <to ..> instead of <from ..>. Eventually I
> figured it out. BTW, I still haven't memorized the definitions of producer
> and consumer in Camelspeak because I can't keep them straight.
>
> Similar to your message queue example, I load data from the mail component
> on-demand. I create a route on the fly and remove it when all mail has been
> consumed (I had to modify the component to make that happen - I will submit
> a patch when I have implemented something that doesn't look like botched
> surgery and I have finished other mods).
>
> Anyone who has ever tried removing a route knows that it ain't pretty.
> Underneath the covers, the overhead in terms of memory and other resources
> (eg thread) of creating and removing routes is not trivial.
>
> I think <from ..> has its place (asynchronous 'static' processing - such as
> reading from the same JMS queue for eternity) but component designers need
> to support <to ..> as well, like the mongodb example. If "dynamic on-demand
> <from" will be possible in Camel 3.0, that would be fantastic.
>
>
> ~cg
>
>
>
> On Wed, Jun 4, 2014 at 10:36 PM, Claus Ibsen <claus.ibsen@gmail.com>
> wrote:
>
> > On Thu, Jun 5, 2014 at 2:06 AM, Henrique Viecili <viecili@gmail.com>
> > wrote:
> > > I faced the same issue in similar scenarios which forced me to use
> Claim
> > > Check in the aggregation strategy. I cannot recall exactly the reason,
> > but
> > > if I'm not wrong a while ago Claus commented about this limitation here
> > in
> > > the mailing list.
> > >
> >
> > Yeah see the content enricher eip page, about pollEnrich, and the red
> > box on that page.
> > And we got a JIRA ticket to improved this. But requires an API change
> > for Camel 3.0.
> >
> >
> > > Anyway, it would be a great improvement.
> > >
> > > Regards,
> > > Henriqeu Viecili
> > >
> > > Henrique Viecili
> > >
> > >
> > > On 5 June 2014 00:47, kraythe . <kraythe@gmail.com> wrote:
> > >
> > >> I am working on some routes which use servlet: endpoints to create a
> > REST
> > >> api for a Ajax UI application. While working on it I am constantly
> > plagued
> > >> by the thought that there is a missing use case, a massive one in
> camel.
> > >>
> > >> Suppose you want to serve a file to a user. They send you some
> parameter
> > >> and you use that to select the appropriate file to return. Currently
> > there
> > >> is no way to do such a thing with camel, so you are forced to use a
> > >> processor and implement the logic yourself. What you need to do is
> > enrich
> > >> the current exchange with information from outside that exchange but
> in
> > a
> > >> consumer manner. What you really need is something like:
> > >>
> > >> from("servlet:downloadFile")
> > >>   // logic to figure out what filename
> > >>   .enrich("file://a/b/c")
> > >>   .end();
> > >>
> > >> Sure this particular use case can be implemented with a processor:
> > >>
> > >> from("servlet:downloadFile)
> > >>   // logic to figure out what filename
> > >>   .process(new Processor() {
> > >>      public void process(final Exchange exchange) {
> > >>         // code to create an IOStream and set it as body.
> > >>      }
> > >>   }
> > >>
> > >> This is an acceptable workaround in this case but it violates the
> > beautiful
> > >> component architecture. If I wanted to enrich from a JMS queue
> > >> ("servlet:nextTicket") I would have to implement queue connectivity
> > myself.
> > >> Less than sub par.
> > >>
> > >> It seems to me that camel needs to have a new use case
> "consumeEnrich()"
> > >> where a consumer can be fired and then aggregated into the current
> > >> exchange. In order to support this we need to add the ability for
> > on-demand
> > >> consumption: i.e.
> > >>
> > >> public interface SupportsConsumeEnrich {
> > >>   public Exchange consumeNow();
> > >> }
> > >>
> > >> Any endpoint that then implements SupportsConsumeEnrich can then be
> > used in
> > >> the consumeEnrich DSL. What do you think?
> > >>
> > >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> > >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> > >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> > >> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
> > >>
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > Red Hat, Inc.
> > Email: cibsen@redhat.com
> > Twitter: davsclaus
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> > hawtio: http://hawt.io/
> > fabric8: http://fabric8.io/
> >
>

--047d7bd6b87ce400d804fb1a6eb8--