You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by Steve973 <st...@gmail.com> on 2021/12/25 15:44:09 UTC

Issue CAMEL-17154: Request for comment and review

Hello.  I have sent a few messages here on this list about an alternate
Dynamic Router EIP component implementation that I have been working on.
If anyone has some time, I would like to get more community input and
opinion on what I have done so far.  You can see the ticket here:

https://issues.apache.org/jira/browse/CAMEL-17154

It contains a link to the component module on my fork of the Camel repo (in
the comments), and I have included a blog post draft ODT attachment that
introduces this component, why I wanted to implement it, and basic
discussion on how to use it.

If any of you would be kind enough to take a quick glance and let me know
what you think, I would be quite grateful.

Happy holidays, if you are celebrating.  Take care, and be well, regardless.

Thanks,
Steve

Re: Issue CAMEL-17154: Request for comment and review

Posted by Claus Ibsen <cl...@gmail.com>.

Hi Steven

Thanks for your patience in my slow feedback.


On Fri, Jan 7, 2022 at 9:07 PM Steve973 <st...@gmail.com> wrote:
>
> Hi, Claus.  Thanks for the feedback.  I think my perspective is a little
> bit different, so let's look at it a slightly different way, and see what
> you think.
>
> To me, the usefulness of Camel comes with having so many things to choose
> from.  Anything isolated might have quite limited usefulness when viewed on
> its own.  But, the fact that you can compose your integration through
> routing and mediation from a huge arsenal of components, processors, and
> other tools, means that you can do quite a lot.  Now, Camel core already
> has a dynamic router.  What is your opinion of its usefulness?  The
> implementation, as it currently stands, is not inherently dynamic.  It uses
> a routing slip, and you would have to "roll your own" routing slip that is
> actually dynamic.  The re-circulation behavior is interesting, but it is a
> misinterpretation of the control channel.
>

Yes I agree the current dynamic router is more of a dynamic routing
list with a while loop.
But it does dynamic routing, but not 100% according to the 15 years
old design from the EIP book.

But in retrospect it would have been better to have added an option on
the existing routing slip,
to turn it into a dynamic mode, and thus we had it as a single EIP.



> I see your point about the in-memory-only queue.  But, with the idea of
> composition that I discussed above, a route that feeds the Dynamic Router
> component can consume messages from anywhere, and the destination URIs can
> be literally any of the endpoints that you can set up and use with Camel.
> It is as scalable as a developer wants to make it.  It provides something a
> bit similar to the dynamic router processor in core, but it is much more
> dynamic without having the requirement of the developer to make the slip
> dynamic.  It provides additional use cases to the dynamic router processor
> in core.
>

It's scalable within a single CamelContext.


> This seems directly applicable to your statement about Camel being the
> "glue".  This is yet more glue; I had originally wanted to make this
> available alongside the current dynamic router in core, but I took your
> advice and made it a component, instead.  Is it not OK for a component to
> provide more glue?
>

Yes sure it shows the versatility of Camel that it is very pluggable.


> Thanks,
> Steve
>
> On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> > Hi Steve
> >
> > We can see from your work that you have put a lot of effort and
> > devotion into this, with an example and blog post as well.
> >
> > However you say that the reason you wanted this was due to the dynamic
> > pattern in the EIP book.
> >
> > The issue is that the EIP book is about messaging and integration
> > patterns and that these patterns
> > does not apply to all software projects.
> >
> > The dynamic pattern as in the EIP book is actuall a pattern in
> > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> > them out there.
> > They all offer a way for clients to subscribe and unsubscribe to
> > topics (and or queues) and very often have filtering as well so a
> > client can say they the only want message that matches X criteria.
> >
> > In other words its a domain that is for a messaging system, and this
> > gets quickly complex when you have distributed systems, and HA with
> > failover, and now also with "the cloud", and even across multiple
> > cloud vendors with hybrid cloud.
> > Your implementation in Camel would be very limited in use-case as its
> > a single context / in-memory only "queue".
> >
> >
> > If on the other hand there was a new messaging system (called foobar),
> > and it was a well used system, then it would be worthwhile to
> > implement a camel component for such system.
> > In other words Camel is the glue to systems, but its "not a "server"
> > system itself".
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> > >
> > > Hello.  I have sent a few messages here on this list about an alternate
> > > Dynamic Router EIP component implementation that I have been working on.
> > > If anyone has some time, I would like to get more community input and
> > > opinion on what I have done so far.  You can see the ticket here:
> > >
> > > https://issues.apache.org/jira/browse/CAMEL-17154
> > >
> > > It contains a link to the component module on my fork of the Camel repo
> > (in
> > > the comments), and I have included a blog post draft ODT attachment that
> > > introduces this component, why I wanted to implement it, and basic
> > > discussion on how to use it.
> > >
> > > If any of you would be kind enough to take a quick glance and let me know
> > > what you think, I would be quite grateful.
> > >
> > > Happy holidays, if you are celebrating.  Take care, and be well,
> > regardless.
> > >
> > > Thanks,
> > > Steve
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Hi, Claus.  Thanks for the feedback.  I think my perspective is a little
bit different, so let's look at it a slightly different way, and see what
you think.

To me, the usefulness of Camel comes with having so many things to choose
from.  Anything isolated might have quite limited usefulness when viewed on
its own.  But, the fact that you can compose your integration through
routing and mediation from a huge arsenal of components, processors, and
other tools, means that you can do quite a lot.  Now, Camel core already
has a dynamic router.  What is your opinion of its usefulness?  The
implementation, as it currently stands, is not inherently dynamic.  It uses
a routing slip, and you would have to "roll your own" routing slip that is
actually dynamic.  The re-circulation behavior is interesting, but it is a
misinterpretation of the control channel.

I see your point about the in-memory-only queue.  But, with the idea of
composition that I discussed above, a route that feeds the Dynamic Router
component can consume messages from anywhere, and the destination URIs can
be literally any of the endpoints that you can set up and use with Camel.
It is as scalable as a developer wants to make it.  It provides something a
bit similar to the dynamic router processor in core, but it is much more
dynamic without having the requirement of the developer to make the slip
dynamic.  It provides additional use cases to the dynamic router processor
in core.

This seems directly applicable to your statement about Camel being the
"glue".  This is yet more glue; I had originally wanted to make this
available alongside the current dynamic router in core, but I took your
advice and made it a component, instead.  Is it not OK for a component to
provide more glue?

Thanks,
Steve

On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:

> Hi Steve
>
> We can see from your work that you have put a lot of effort and
> devotion into this, with an example and blog post as well.
>
> However you say that the reason you wanted this was due to the dynamic
> pattern in the EIP book.
>
> The issue is that the EIP book is about messaging and integration
> patterns and that these patterns
> does not apply to all software projects.
>
> The dynamic pattern as in the EIP book is actuall a pattern in
> messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> them out there.
> They all offer a way for clients to subscribe and unsubscribe to
> topics (and or queues) and very often have filtering as well so a
> client can say they the only want message that matches X criteria.
>
> In other words its a domain that is for a messaging system, and this
> gets quickly complex when you have distributed systems, and HA with
> failover, and now also with "the cloud", and even across multiple
> cloud vendors with hybrid cloud.
> Your implementation in Camel would be very limited in use-case as its
> a single context / in-memory only "queue".
>
>
> If on the other hand there was a new messaging system (called foobar),
> and it was a well used system, then it would be worthwhile to
> implement a camel component for such system.
> In other words Camel is the glue to systems, but its "not a "server"
> system itself".
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> >
> > Hello.  I have sent a few messages here on this list about an alternate
> > Dynamic Router EIP component implementation that I have been working on.
> > If anyone has some time, I would like to get more community input and
> > opinion on what I have done so far.  You can see the ticket here:
> >
> > https://issues.apache.org/jira/browse/CAMEL-17154
> >
> > It contains a link to the component module on my fork of the Camel repo
> (in
> > the comments), and I have included a blog post draft ODT attachment that
> > introduces this component, why I wanted to implement it, and basic
> > discussion on how to use it.
> >
> > If any of you would be kind enough to take a quick glance and let me know
> > what you think, I would be quite grateful.
> >
> > Happy holidays, if you are celebrating.  Take care, and be well,
> regardless.
> >
> > Thanks,
> > Steve
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

I was able to try now, and I get a different error message:

[ERROR] error An unexpected error occurred: "Unknown token: { line: 3, col:
2, type: 'INVALID', value: undefined } 3:2 in
/home/steve/IdeaProjects/camel-website/yarn.lock".

I tried "mvn package" and "mvn clean package" to try to build it.

Thanks,
Steve

On Wed, Jan 12, 2022 at 1:13 AM Claus Ibsen <cl...@gmail.com> wrote:

> Hi
>
> Can you try again as there was some left over we forgot to delete
> after a starter was removed (spring-javaconfig)
>
> On Wed, Jan 12, 2022 at 12:44 AM Steve973 <st...@gmail.com> wrote:
> >
> > I am having a very hard time getting camel-website to build.  it keeps
> > saying:
> >
> > ➤ YN0000: [18:20:41] Finished 'bundle' after 26 s
> > ➤ YN0000:
> >
> {"level":"error","time":1641943633792,"name":"asciidoctor","file":{"path":"docs/spring-boot/modules/ROOT/pages/list.adoc","line":19},"source":{"url":"
> > https://github.com/apache/camel-spring-boot.git
> ","refname":"main","startPath":"docs/spring-boot"},"msg":"target
> > of include not found: Error-unused-starter-json.adoc"}
> > ➤ YN0000: ERROR: "build:antora-perf" exited with 1.
> > ➤ YN0000: ERROR: "build:antora" exited with 1.
> > ➤ YN0000: The command failed for workspaces that are depended upon by
> other
> > workspaces; can't satisfy the dependency graph
> > ➤ YN0000: Failed with errors in 8m 59s
> >
> > On Tue, Jan 11, 2022 at 2:47 PM Steve973 <st...@gmail.com> wrote:
> >
> > > Oh, I am not sure what you mean with regard to the date.  The text does
> > > not contain the date.
> > >
> > > On Tue, Jan 11, 2022 at 2:46 PM Steve973 <st...@gmail.com> wrote:
> > >
> > >> Since this is my first contribution to one of my all-time favorite
> > >> libraries, this is pretty exciting for me.  I would be glad to update
> the
> > >> blog post immediately.  I will also add the things that we discussed
> with
> > >> regard to how this is a glue component, etc etc.  If you need me to
> change
> > >> (or shorten) it, let me know and I can turn that around quickly, as
> well.
> > >>
> > >> On Tue, Jan 11, 2022 at 2:06 PM Claus Ibsen <cl...@gmail.com>
> > >> wrote:
> > >>
> > >>> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <st...@gmail.com> wrote:
> > >>> >
> > >>> > Thank you for the review and comments.  I completely agree with you
> > >>> that it
> > >>> > is cumbersome to require users to create a java object.  Your
> > >>> suggestion of
> > >>> > making the subscription URI-based is good, and I still need to
> figure
> > >>> out
> > >>> > how to provide the filter (Predicate) for evaluating exchanges for
> > >>> > participant suitability.  Do you think that including a Camel bean
> ID
> > >>> in
> > >>> > the url (and a corresponding bean in the registry) for the
> Predicate
> > >>> would
> > >>> > be a good approach?
> > >>> >
> > >>>
> > >>> Yes we could allow both kind, eg the user can send the java object
> and
> > >>> have full control from java.
> > >>>
> > >>> Then in the uri, you can have a filter parameter of type predicate.
> > >>> Then in the uri you can refer to a bean with the #bean:myFilter
> > >>> syntax.
> > >>> If you think that a predicate based on the simple language makes
> > >>> sense, then we could also use that via the uri
> > >>>
> > >>> filter=${body} > 100
> > >>>
> > >>> The file component has some option that allows this, but lets fight
> > >>> one battle at a time, and just get a #bean:xxx syntax to work first.
> > >>>
> > >>>
> > >>> But before doing all of this, then I think the current PR can be
> merged
> > >>> as is.
> > >>>
> > >>> Can you update the blog post date to today?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> > On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <claus.ibsen@gmail.com
> >
> > >>> wrote:
> > >>> >
> > >>> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com>
> wrote:
> > >>> > > >
> > >>> > > > Hello.  I would like to add a little more to this conversation,
> > >>> since you
> > >>> > > > mentioned my reason for contributing this code.  My motivation
> to
> > >>> add
> > >>> > > this
> > >>> > > > EIP component was because a couple of years ago, I read about
> the
> > >>> dynamic
> > >>> > > > router EIP within Camel, and I thought that it would be perfect
> > >>> for what
> > >>> > > I
> > >>> > > > needed to do in my project at work.  It looked like my clients
> > >>> could
> > >>> > > > register with the dynamic router processor, but further
> reading of
> > >>> the
> > >>> > > docs
> > >>> > > > and my own use of it revealed that this was not how it was
> > >>> implemented.
> > >>> > > I
> > >>> > > > was not able to use it for my use case, but I had to move on
> and
> > >>> > > implement
> > >>> > > > this behavior myself.
> > >>> > > >
> > >>> > > > Now that I had some time, I thought that I would contribute
> this
> > >>> idea to
> > >>> > > > Camel so that others would be able to use this particular type
> of
> > >>> "glue"
> > >>> > > > right out of the box that fits use cases that are like others
> in
> > >>> camel,
> > >>> > > but
> > >>> > > > expanded in certain areas that include, but are probably not
> > >>> limited to:
> > >>> > > >
> > >>> > > >    - the content-based router (choice), but the choices are
> fully
> > >>> > > >    subscriber-initiated and do not need to be known at compile
> time
> > >>> > > >    - the dynamic router (processor in Camel core), and I
> outlined
> > >>> the
> > >>> > > >    differences in the previous email, so no need to re-hash
> here
> > >>> > > >    - the message filter, but instead of creating the filter at
> > >>> compile
> > >>> > > >    time, consumers provide their own filter at runtime
> > >>> > > >    - the selective consumer, but turned the other way around:
> > >>> instead of
> > >>> > > >    sending messages to (potentially a list of) recipients, and
> > >>> letting
> > >>> > > them
> > >>> > > >    all determine which messages to process or discard, this
> > >>> component
> > >>> > > allows a
> > >>> > > >    consumer to subscribe with its filter so that the router can
> > >>> handle
> > >>> > > this
> > >>> > > >    (centrally) and only send messages to the (first)
> appropriate
> > >>> > > subscriber.
> > >>> > > >    If we need a recipient list mode, that can easily be added
> so
> > >>> that it
> > >>> > > sends
> > >>> > > >    to all matching recipients.
> > >>> > > >    - the "To Dynamic" EIP, but the sender does not need to know
> > >>> about
> > >>> > > >    dynamic recipients, and variables do not have to be set
> > >>> > > >
> > >>> > >
> > >>> > > That is a good break-down and perspective
> > >>> > >
> > >>> > > > I hope this shows how this contribution is not only "glue", but
> > >>> that it
> > >>> > > is
> > >>> > > > useful glue that provides simplified routing for developers
> that
> > >>> have use
> > >>> > > > cases that overlap in the list of features above.  While you
> could
> > >>> > > achieve
> > >>> > > > anything in software by composing a solution of several
> different
> > >>> pieces,
> > >>> > > > and implementing the glue that helps them to work together
> and, in
> > >>> this
> > >>> > > > case, also implementing the runtime registration of recipients,
> > >>> this
> > >>> > > > component ties these things together and makes it simple.  It
> is
> > >>> not
> > >>> > > > intended to be its own messaging system, but to facilitate
> > >>> messaging to,
> > >>> > > > and from, other sources where the decision is truly
> runtime-based.
> > >>> > > Indeed,
> > >>> > > > you might have another messaging system that provides
> filtering,
> > >>> etc, but
> > >>> > > > this component introduces a new feature to provide this in a
> way
> > >>> that is
> > >>> > > > independent of other components/transports, and can,
> therefore, be
> > >>> used
> > >>> > > as
> > >>> > > > a dynamic integration point between completely different
> messaging
> > >>> > > systems.
> > >>> > > >
> > >>> > >
> > >>> > > Yes I can see the validation, when you accept that it's not a
> > >>> > > messaging system with client/server actors.
> > >>> > > So when you say that you can subscribe/unsubscribe then it's not
> on
> > >>> > > the same page as it would be with a JMS/Kafka client that
> subscribes
> > >>> > > to a broker system.
> > >>> > >
> > >>> > > I wonder if you could research if you can make the subscription
> > >>> > > simpler, as I think it's a little bit of a "hurdle" that Camel
> users
> > >>> > > would
> > >>> > > need to construct a java object to subscribe for basic
> subscription.
> > >>> > >
> > >>> > > You could have sub context for the action and channel, so if you
> just
> > >>> > > want to subscribe you can send an empty message to
> > >>> > >
> > >>> > > dynamic-router:control/subscribe/my-channel?id=123
> > >>> > >
> > >>> > > You could also allow to auto-gen uuid for the subscription id,
> so if
> > >>> > > id is omitted then one is returned
> > >>> > >
> > >>> > > String uid = requestBody(....)
> > >>> > >
> > >>> > > Anyway that is food for thoughts for improvements.
> > >>> > >
> > >>> > > What you have sent today as PR - lets review it. I can see its
> > >>> > > usefulness and its potential if you continue to work on it.
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > > Thanks again,
> > >>> > > > Steve
> > >>> > > >
> > >>> > > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <
> claus.ibsen@gmail.com>
> > >>> > > wrote:
> > >>> > > >
> > >>> > > > > Hi Steve
> > >>> > > > >
> > >>> > > > > We can see from your work that you have put a lot of effort
> and
> > >>> > > > > devotion into this, with an example and blog post as well.
> > >>> > > > >
> > >>> > > > > However you say that the reason you wanted this was due to
> the
> > >>> dynamic
> > >>> > > > > pattern in the EIP book.
> > >>> > > > >
> > >>> > > > > The issue is that the EIP book is about messaging and
> integration
> > >>> > > > > patterns and that these patterns
> > >>> > > > > does not apply to all software projects.
> > >>> > > > >
> > >>> > > > > The dynamic pattern as in the EIP book is actuall a pattern
> in
> > >>> > > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the
> > >>> many of
> > >>> > > > > them out there.
> > >>> > > > > They all offer a way for clients to subscribe and
> unsubscribe to
> > >>> > > > > topics (and or queues) and very often have filtering as well
> so a
> > >>> > > > > client can say they the only want message that matches X
> > >>> criteria.
> > >>> > > > >
> > >>> > > > > In other words its a domain that is for a messaging system,
> and
> > >>> this
> > >>> > > > > gets quickly complex when you have distributed systems, and
> HA
> > >>> with
> > >>> > > > > failover, and now also with "the cloud", and even across
> multiple
> > >>> > > > > cloud vendors with hybrid cloud.
> > >>> > > > > Your implementation in Camel would be very limited in
> use-case
> > >>> as its
> > >>> > > > > a single context / in-memory only "queue".
> > >>> > > > >
> > >>> > > > >
> > >>> > > > > If on the other hand there was a new messaging system (called
> > >>> foobar),
> > >>> > > > > and it was a well used system, then it would be worthwhile to
> > >>> > > > > implement a camel component for such system.
> > >>> > > > > In other words Camel is the glue to systems, but its "not a
> > >>> "server"
> > >>> > > > > system itself".
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <steve973@gmail.com
> >
> > >>> wrote:
> > >>> > > > > >
> > >>> > > > > > Hello.  I have sent a few messages here on this list about
> an
> > >>> > > alternate
> > >>> > > > > > Dynamic Router EIP component implementation that I have
> been
> > >>> working
> > >>> > > on.
> > >>> > > > > > If anyone has some time, I would like to get more community
> > >>> input and
> > >>> > > > > > opinion on what I have done so far.  You can see the ticket
> > >>> here:
> > >>> > > > > >
> > >>> > > > > > https://issues.apache.org/jira/browse/CAMEL-17154
> > >>> > > > > >
> > >>> > > > > > It contains a link to the component module on my fork of
> the
> > >>> Camel
> > >>> > > repo
> > >>> > > > > (in
> > >>> > > > > > the comments), and I have included a blog post draft ODT
> > >>> attachment
> > >>> > > that
> > >>> > > > > > introduces this component, why I wanted to implement it,
> and
> > >>> basic
> > >>> > > > > > discussion on how to use it.
> > >>> > > > > >
> > >>> > > > > > If any of you would be kind enough to take a quick glance
> and
> > >>> let me
> > >>> > > know
> > >>> > > > > > what you think, I would be quite grateful.
> > >>> > > > > >
> > >>> > > > > > Happy holidays, if you are celebrating.  Take care, and be
> > >>> well,
> > >>> > > > > regardless.
> > >>> > > > > >
> > >>> > > > > > Thanks,
> > >>> > > > > > Steve
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > > > > --
> > >>> > > > > Claus Ibsen
> > >>> > > > > -----------------
> > >>> > > > > http://davsclaus.com @davsclaus
> > >>> > > > > Camel in Action 2: https://www.manning.com/ibsen2
> > >>> > > > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > --
> > >>> > > Claus Ibsen
> > >>> > > -----------------
> > >>> > > http://davsclaus.com @davsclaus
> > >>> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >>> > >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Claus Ibsen
> > >>> -----------------
> > >>> http://davsclaus.com @davsclaus
> > >>> Camel in Action 2: https://www.manning.com/ibsen2
> > >>>
> > >>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

Can you try again as there was some left over we forgot to delete
after a starter was removed (spring-javaconfig)

On Wed, Jan 12, 2022 at 12:44 AM Steve973 <st...@gmail.com> wrote:
>
> I am having a very hard time getting camel-website to build.  it keeps
> saying:
>
> ➤ YN0000: [18:20:41] Finished 'bundle' after 26 s
> ➤ YN0000:
> {"level":"error","time":1641943633792,"name":"asciidoctor","file":{"path":"docs/spring-boot/modules/ROOT/pages/list.adoc","line":19},"source":{"url":"
> https://github.com/apache/camel-spring-boot.git","refname":"main","startPath":"docs/spring-boot"},"msg":"target
> of include not found: Error-unused-starter-json.adoc"}
> ➤ YN0000: ERROR: "build:antora-perf" exited with 1.
> ➤ YN0000: ERROR: "build:antora" exited with 1.
> ➤ YN0000: The command failed for workspaces that are depended upon by other
> workspaces; can't satisfy the dependency graph
> ➤ YN0000: Failed with errors in 8m 59s
>
> On Tue, Jan 11, 2022 at 2:47 PM Steve973 <st...@gmail.com> wrote:
>
> > Oh, I am not sure what you mean with regard to the date.  The text does
> > not contain the date.
> >
> > On Tue, Jan 11, 2022 at 2:46 PM Steve973 <st...@gmail.com> wrote:
> >
> >> Since this is my first contribution to one of my all-time favorite
> >> libraries, this is pretty exciting for me.  I would be glad to update the
> >> blog post immediately.  I will also add the things that we discussed with
> >> regard to how this is a glue component, etc etc.  If you need me to change
> >> (or shorten) it, let me know and I can turn that around quickly, as well.
> >>
> >> On Tue, Jan 11, 2022 at 2:06 PM Claus Ibsen <cl...@gmail.com>
> >> wrote:
> >>
> >>> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <st...@gmail.com> wrote:
> >>> >
> >>> > Thank you for the review and comments.  I completely agree with you
> >>> that it
> >>> > is cumbersome to require users to create a java object.  Your
> >>> suggestion of
> >>> > making the subscription URI-based is good, and I still need to figure
> >>> out
> >>> > how to provide the filter (Predicate) for evaluating exchanges for
> >>> > participant suitability.  Do you think that including a Camel bean ID
> >>> in
> >>> > the url (and a corresponding bean in the registry) for the Predicate
> >>> would
> >>> > be a good approach?
> >>> >
> >>>
> >>> Yes we could allow both kind, eg the user can send the java object and
> >>> have full control from java.
> >>>
> >>> Then in the uri, you can have a filter parameter of type predicate.
> >>> Then in the uri you can refer to a bean with the #bean:myFilter
> >>> syntax.
> >>> If you think that a predicate based on the simple language makes
> >>> sense, then we could also use that via the uri
> >>>
> >>> filter=${body} > 100
> >>>
> >>> The file component has some option that allows this, but lets fight
> >>> one battle at a time, and just get a #bean:xxx syntax to work first.
> >>>
> >>>
> >>> But before doing all of this, then I think the current PR can be merged
> >>> as is.
> >>>
> >>> Can you update the blog post date to today?
> >>>
> >>>
> >>>
> >>>
> >>> > On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com>
> >>> wrote:
> >>> >
> >>> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
> >>> > > >
> >>> > > > Hello.  I would like to add a little more to this conversation,
> >>> since you
> >>> > > > mentioned my reason for contributing this code.  My motivation to
> >>> add
> >>> > > this
> >>> > > > EIP component was because a couple of years ago, I read about the
> >>> dynamic
> >>> > > > router EIP within Camel, and I thought that it would be perfect
> >>> for what
> >>> > > I
> >>> > > > needed to do in my project at work.  It looked like my clients
> >>> could
> >>> > > > register with the dynamic router processor, but further reading of
> >>> the
> >>> > > docs
> >>> > > > and my own use of it revealed that this was not how it was
> >>> implemented.
> >>> > > I
> >>> > > > was not able to use it for my use case, but I had to move on and
> >>> > > implement
> >>> > > > this behavior myself.
> >>> > > >
> >>> > > > Now that I had some time, I thought that I would contribute this
> >>> idea to
> >>> > > > Camel so that others would be able to use this particular type of
> >>> "glue"
> >>> > > > right out of the box that fits use cases that are like others in
> >>> camel,
> >>> > > but
> >>> > > > expanded in certain areas that include, but are probably not
> >>> limited to:
> >>> > > >
> >>> > > >    - the content-based router (choice), but the choices are fully
> >>> > > >    subscriber-initiated and do not need to be known at compile time
> >>> > > >    - the dynamic router (processor in Camel core), and I outlined
> >>> the
> >>> > > >    differences in the previous email, so no need to re-hash here
> >>> > > >    - the message filter, but instead of creating the filter at
> >>> compile
> >>> > > >    time, consumers provide their own filter at runtime
> >>> > > >    - the selective consumer, but turned the other way around:
> >>> instead of
> >>> > > >    sending messages to (potentially a list of) recipients, and
> >>> letting
> >>> > > them
> >>> > > >    all determine which messages to process or discard, this
> >>> component
> >>> > > allows a
> >>> > > >    consumer to subscribe with its filter so that the router can
> >>> handle
> >>> > > this
> >>> > > >    (centrally) and only send messages to the (first) appropriate
> >>> > > subscriber.
> >>> > > >    If we need a recipient list mode, that can easily be added so
> >>> that it
> >>> > > sends
> >>> > > >    to all matching recipients.
> >>> > > >    - the "To Dynamic" EIP, but the sender does not need to know
> >>> about
> >>> > > >    dynamic recipients, and variables do not have to be set
> >>> > > >
> >>> > >
> >>> > > That is a good break-down and perspective
> >>> > >
> >>> > > > I hope this shows how this contribution is not only "glue", but
> >>> that it
> >>> > > is
> >>> > > > useful glue that provides simplified routing for developers that
> >>> have use
> >>> > > > cases that overlap in the list of features above.  While you could
> >>> > > achieve
> >>> > > > anything in software by composing a solution of several different
> >>> pieces,
> >>> > > > and implementing the glue that helps them to work together and, in
> >>> this
> >>> > > > case, also implementing the runtime registration of recipients,
> >>> this
> >>> > > > component ties these things together and makes it simple.  It is
> >>> not
> >>> > > > intended to be its own messaging system, but to facilitate
> >>> messaging to,
> >>> > > > and from, other sources where the decision is truly runtime-based.
> >>> > > Indeed,
> >>> > > > you might have another messaging system that provides filtering,
> >>> etc, but
> >>> > > > this component introduces a new feature to provide this in a way
> >>> that is
> >>> > > > independent of other components/transports, and can, therefore, be
> >>> used
> >>> > > as
> >>> > > > a dynamic integration point between completely different messaging
> >>> > > systems.
> >>> > > >
> >>> > >
> >>> > > Yes I can see the validation, when you accept that it's not a
> >>> > > messaging system with client/server actors.
> >>> > > So when you say that you can subscribe/unsubscribe then it's not on
> >>> > > the same page as it would be with a JMS/Kafka client that subscribes
> >>> > > to a broker system.
> >>> > >
> >>> > > I wonder if you could research if you can make the subscription
> >>> > > simpler, as I think it's a little bit of a "hurdle" that Camel users
> >>> > > would
> >>> > > need to construct a java object to subscribe for basic subscription.
> >>> > >
> >>> > > You could have sub context for the action and channel, so if you just
> >>> > > want to subscribe you can send an empty message to
> >>> > >
> >>> > > dynamic-router:control/subscribe/my-channel?id=123
> >>> > >
> >>> > > You could also allow to auto-gen uuid for the subscription id, so if
> >>> > > id is omitted then one is returned
> >>> > >
> >>> > > String uid = requestBody(....)
> >>> > >
> >>> > > Anyway that is food for thoughts for improvements.
> >>> > >
> >>> > > What you have sent today as PR - lets review it. I can see its
> >>> > > usefulness and its potential if you continue to work on it.
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > > Thanks again,
> >>> > > > Steve
> >>> > > >
> >>> > > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
> >>> > > wrote:
> >>> > > >
> >>> > > > > Hi Steve
> >>> > > > >
> >>> > > > > We can see from your work that you have put a lot of effort and
> >>> > > > > devotion into this, with an example and blog post as well.
> >>> > > > >
> >>> > > > > However you say that the reason you wanted this was due to the
> >>> dynamic
> >>> > > > > pattern in the EIP book.
> >>> > > > >
> >>> > > > > The issue is that the EIP book is about messaging and integration
> >>> > > > > patterns and that these patterns
> >>> > > > > does not apply to all software projects.
> >>> > > > >
> >>> > > > > The dynamic pattern as in the EIP book is actuall a pattern in
> >>> > > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the
> >>> many of
> >>> > > > > them out there.
> >>> > > > > They all offer a way for clients to subscribe and unsubscribe to
> >>> > > > > topics (and or queues) and very often have filtering as well so a
> >>> > > > > client can say they the only want message that matches X
> >>> criteria.
> >>> > > > >
> >>> > > > > In other words its a domain that is for a messaging system, and
> >>> this
> >>> > > > > gets quickly complex when you have distributed systems, and HA
> >>> with
> >>> > > > > failover, and now also with "the cloud", and even across multiple
> >>> > > > > cloud vendors with hybrid cloud.
> >>> > > > > Your implementation in Camel would be very limited in use-case
> >>> as its
> >>> > > > > a single context / in-memory only "queue".
> >>> > > > >
> >>> > > > >
> >>> > > > > If on the other hand there was a new messaging system (called
> >>> foobar),
> >>> > > > > and it was a well used system, then it would be worthwhile to
> >>> > > > > implement a camel component for such system.
> >>> > > > > In other words Camel is the glue to systems, but its "not a
> >>> "server"
> >>> > > > > system itself".
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com>
> >>> wrote:
> >>> > > > > >
> >>> > > > > > Hello.  I have sent a few messages here on this list about an
> >>> > > alternate
> >>> > > > > > Dynamic Router EIP component implementation that I have been
> >>> working
> >>> > > on.
> >>> > > > > > If anyone has some time, I would like to get more community
> >>> input and
> >>> > > > > > opinion on what I have done so far.  You can see the ticket
> >>> here:
> >>> > > > > >
> >>> > > > > > https://issues.apache.org/jira/browse/CAMEL-17154
> >>> > > > > >
> >>> > > > > > It contains a link to the component module on my fork of the
> >>> Camel
> >>> > > repo
> >>> > > > > (in
> >>> > > > > > the comments), and I have included a blog post draft ODT
> >>> attachment
> >>> > > that
> >>> > > > > > introduces this component, why I wanted to implement it, and
> >>> basic
> >>> > > > > > discussion on how to use it.
> >>> > > > > >
> >>> > > > > > If any of you would be kind enough to take a quick glance and
> >>> let me
> >>> > > know
> >>> > > > > > what you think, I would be quite grateful.
> >>> > > > > >
> >>> > > > > > Happy holidays, if you are celebrating.  Take care, and be
> >>> well,
> >>> > > > > regardless.
> >>> > > > > >
> >>> > > > > > Thanks,
> >>> > > > > > Steve
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > > --
> >>> > > > > Claus Ibsen
> >>> > > > > -----------------
> >>> > > > > http://davsclaus.com @davsclaus
> >>> > > > > Camel in Action 2: https://www.manning.com/ibsen2
> >>> > > > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > Claus Ibsen
> >>> > > -----------------
> >>> > > http://davsclaus.com @davsclaus
> >>> > > Camel in Action 2: https://www.manning.com/ibsen2
> >>> > >
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> -----------------
> >>> http://davsclaus.com @davsclaus
> >>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>
> >>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

I am having a very hard time getting camel-website to build.  it keeps
saying:

➤ YN0000: [18:20:41] Finished 'bundle' after 26 s
➤ YN0000:
{"level":"error","time":1641943633792,"name":"asciidoctor","file":{"path":"docs/spring-boot/modules/ROOT/pages/list.adoc","line":19},"source":{"url":"
https://github.com/apache/camel-spring-boot.git","refname":"main","startPath":"docs/spring-boot"},"msg":"target
of include not found: Error-unused-starter-json.adoc"}
➤ YN0000: ERROR: "build:antora-perf" exited with 1.
➤ YN0000: ERROR: "build:antora" exited with 1.
➤ YN0000: The command failed for workspaces that are depended upon by other
workspaces; can't satisfy the dependency graph
➤ YN0000: Failed with errors in 8m 59s

On Tue, Jan 11, 2022 at 2:47 PM Steve973 <st...@gmail.com> wrote:

> Oh, I am not sure what you mean with regard to the date.  The text does
> not contain the date.
>
> On Tue, Jan 11, 2022 at 2:46 PM Steve973 <st...@gmail.com> wrote:
>
>> Since this is my first contribution to one of my all-time favorite
>> libraries, this is pretty exciting for me.  I would be glad to update the
>> blog post immediately.  I will also add the things that we discussed with
>> regard to how this is a glue component, etc etc.  If you need me to change
>> (or shorten) it, let me know and I can turn that around quickly, as well.
>>
>> On Tue, Jan 11, 2022 at 2:06 PM Claus Ibsen <cl...@gmail.com>
>> wrote:
>>
>>> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <st...@gmail.com> wrote:
>>> >
>>> > Thank you for the review and comments.  I completely agree with you
>>> that it
>>> > is cumbersome to require users to create a java object.  Your
>>> suggestion of
>>> > making the subscription URI-based is good, and I still need to figure
>>> out
>>> > how to provide the filter (Predicate) for evaluating exchanges for
>>> > participant suitability.  Do you think that including a Camel bean ID
>>> in
>>> > the url (and a corresponding bean in the registry) for the Predicate
>>> would
>>> > be a good approach?
>>> >
>>>
>>> Yes we could allow both kind, eg the user can send the java object and
>>> have full control from java.
>>>
>>> Then in the uri, you can have a filter parameter of type predicate.
>>> Then in the uri you can refer to a bean with the #bean:myFilter
>>> syntax.
>>> If you think that a predicate based on the simple language makes
>>> sense, then we could also use that via the uri
>>>
>>> filter=${body} > 100
>>>
>>> The file component has some option that allows this, but lets fight
>>> one battle at a time, and just get a #bean:xxx syntax to work first.
>>>
>>>
>>> But before doing all of this, then I think the current PR can be merged
>>> as is.
>>>
>>> Can you update the blog post date to today?
>>>
>>>
>>>
>>>
>>> > On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com>
>>> wrote:
>>> >
>>> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
>>> > > >
>>> > > > Hello.  I would like to add a little more to this conversation,
>>> since you
>>> > > > mentioned my reason for contributing this code.  My motivation to
>>> add
>>> > > this
>>> > > > EIP component was because a couple of years ago, I read about the
>>> dynamic
>>> > > > router EIP within Camel, and I thought that it would be perfect
>>> for what
>>> > > I
>>> > > > needed to do in my project at work.  It looked like my clients
>>> could
>>> > > > register with the dynamic router processor, but further reading of
>>> the
>>> > > docs
>>> > > > and my own use of it revealed that this was not how it was
>>> implemented.
>>> > > I
>>> > > > was not able to use it for my use case, but I had to move on and
>>> > > implement
>>> > > > this behavior myself.
>>> > > >
>>> > > > Now that I had some time, I thought that I would contribute this
>>> idea to
>>> > > > Camel so that others would be able to use this particular type of
>>> "glue"
>>> > > > right out of the box that fits use cases that are like others in
>>> camel,
>>> > > but
>>> > > > expanded in certain areas that include, but are probably not
>>> limited to:
>>> > > >
>>> > > >    - the content-based router (choice), but the choices are fully
>>> > > >    subscriber-initiated and do not need to be known at compile time
>>> > > >    - the dynamic router (processor in Camel core), and I outlined
>>> the
>>> > > >    differences in the previous email, so no need to re-hash here
>>> > > >    - the message filter, but instead of creating the filter at
>>> compile
>>> > > >    time, consumers provide their own filter at runtime
>>> > > >    - the selective consumer, but turned the other way around:
>>> instead of
>>> > > >    sending messages to (potentially a list of) recipients, and
>>> letting
>>> > > them
>>> > > >    all determine which messages to process or discard, this
>>> component
>>> > > allows a
>>> > > >    consumer to subscribe with its filter so that the router can
>>> handle
>>> > > this
>>> > > >    (centrally) and only send messages to the (first) appropriate
>>> > > subscriber.
>>> > > >    If we need a recipient list mode, that can easily be added so
>>> that it
>>> > > sends
>>> > > >    to all matching recipients.
>>> > > >    - the "To Dynamic" EIP, but the sender does not need to know
>>> about
>>> > > >    dynamic recipients, and variables do not have to be set
>>> > > >
>>> > >
>>> > > That is a good break-down and perspective
>>> > >
>>> > > > I hope this shows how this contribution is not only "glue", but
>>> that it
>>> > > is
>>> > > > useful glue that provides simplified routing for developers that
>>> have use
>>> > > > cases that overlap in the list of features above.  While you could
>>> > > achieve
>>> > > > anything in software by composing a solution of several different
>>> pieces,
>>> > > > and implementing the glue that helps them to work together and, in
>>> this
>>> > > > case, also implementing the runtime registration of recipients,
>>> this
>>> > > > component ties these things together and makes it simple.  It is
>>> not
>>> > > > intended to be its own messaging system, but to facilitate
>>> messaging to,
>>> > > > and from, other sources where the decision is truly runtime-based.
>>> > > Indeed,
>>> > > > you might have another messaging system that provides filtering,
>>> etc, but
>>> > > > this component introduces a new feature to provide this in a way
>>> that is
>>> > > > independent of other components/transports, and can, therefore, be
>>> used
>>> > > as
>>> > > > a dynamic integration point between completely different messaging
>>> > > systems.
>>> > > >
>>> > >
>>> > > Yes I can see the validation, when you accept that it's not a
>>> > > messaging system with client/server actors.
>>> > > So when you say that you can subscribe/unsubscribe then it's not on
>>> > > the same page as it would be with a JMS/Kafka client that subscribes
>>> > > to a broker system.
>>> > >
>>> > > I wonder if you could research if you can make the subscription
>>> > > simpler, as I think it's a little bit of a "hurdle" that Camel users
>>> > > would
>>> > > need to construct a java object to subscribe for basic subscription.
>>> > >
>>> > > You could have sub context for the action and channel, so if you just
>>> > > want to subscribe you can send an empty message to
>>> > >
>>> > > dynamic-router:control/subscribe/my-channel?id=123
>>> > >
>>> > > You could also allow to auto-gen uuid for the subscription id, so if
>>> > > id is omitted then one is returned
>>> > >
>>> > > String uid = requestBody(....)
>>> > >
>>> > > Anyway that is food for thoughts for improvements.
>>> > >
>>> > > What you have sent today as PR - lets review it. I can see its
>>> > > usefulness and its potential if you continue to work on it.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > > Thanks again,
>>> > > > Steve
>>> > > >
>>> > > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > > Hi Steve
>>> > > > >
>>> > > > > We can see from your work that you have put a lot of effort and
>>> > > > > devotion into this, with an example and blog post as well.
>>> > > > >
>>> > > > > However you say that the reason you wanted this was due to the
>>> dynamic
>>> > > > > pattern in the EIP book.
>>> > > > >
>>> > > > > The issue is that the EIP book is about messaging and integration
>>> > > > > patterns and that these patterns
>>> > > > > does not apply to all software projects.
>>> > > > >
>>> > > > > The dynamic pattern as in the EIP book is actuall a pattern in
>>> > > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the
>>> many of
>>> > > > > them out there.
>>> > > > > They all offer a way for clients to subscribe and unsubscribe to
>>> > > > > topics (and or queues) and very often have filtering as well so a
>>> > > > > client can say they the only want message that matches X
>>> criteria.
>>> > > > >
>>> > > > > In other words its a domain that is for a messaging system, and
>>> this
>>> > > > > gets quickly complex when you have distributed systems, and HA
>>> with
>>> > > > > failover, and now also with "the cloud", and even across multiple
>>> > > > > cloud vendors with hybrid cloud.
>>> > > > > Your implementation in Camel would be very limited in use-case
>>> as its
>>> > > > > a single context / in-memory only "queue".
>>> > > > >
>>> > > > >
>>> > > > > If on the other hand there was a new messaging system (called
>>> foobar),
>>> > > > > and it was a well used system, then it would be worthwhile to
>>> > > > > implement a camel component for such system.
>>> > > > > In other words Camel is the glue to systems, but its "not a
>>> "server"
>>> > > > > system itself".
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com>
>>> wrote:
>>> > > > > >
>>> > > > > > Hello.  I have sent a few messages here on this list about an
>>> > > alternate
>>> > > > > > Dynamic Router EIP component implementation that I have been
>>> working
>>> > > on.
>>> > > > > > If anyone has some time, I would like to get more community
>>> input and
>>> > > > > > opinion on what I have done so far.  You can see the ticket
>>> here:
>>> > > > > >
>>> > > > > > https://issues.apache.org/jira/browse/CAMEL-17154
>>> > > > > >
>>> > > > > > It contains a link to the component module on my fork of the
>>> Camel
>>> > > repo
>>> > > > > (in
>>> > > > > > the comments), and I have included a blog post draft ODT
>>> attachment
>>> > > that
>>> > > > > > introduces this component, why I wanted to implement it, and
>>> basic
>>> > > > > > discussion on how to use it.
>>> > > > > >
>>> > > > > > If any of you would be kind enough to take a quick glance and
>>> let me
>>> > > know
>>> > > > > > what you think, I would be quite grateful.
>>> > > > > >
>>> > > > > > Happy holidays, if you are celebrating.  Take care, and be
>>> well,
>>> > > > > regardless.
>>> > > > > >
>>> > > > > > Thanks,
>>> > > > > > Steve
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > --
>>> > > > > Claus Ibsen
>>> > > > > -----------------
>>> > > > > http://davsclaus.com @davsclaus
>>> > > > > Camel in Action 2: https://www.manning.com/ibsen2
>>> > > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Claus Ibsen
>>> > > -----------------
>>> > > http://davsclaus.com @davsclaus
>>> > > Camel in Action 2: https://www.manning.com/ibsen2
>>> > >
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Oh, I am not sure what you mean with regard to the date.  The text does not
contain the date.

On Tue, Jan 11, 2022 at 2:46 PM Steve973 <st...@gmail.com> wrote:

> Since this is my first contribution to one of my all-time favorite
> libraries, this is pretty exciting for me.  I would be glad to update the
> blog post immediately.  I will also add the things that we discussed with
> regard to how this is a glue component, etc etc.  If you need me to change
> (or shorten) it, let me know and I can turn that around quickly, as well.
>
> On Tue, Jan 11, 2022 at 2:06 PM Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <st...@gmail.com> wrote:
>> >
>> > Thank you for the review and comments.  I completely agree with you
>> that it
>> > is cumbersome to require users to create a java object.  Your
>> suggestion of
>> > making the subscription URI-based is good, and I still need to figure
>> out
>> > how to provide the filter (Predicate) for evaluating exchanges for
>> > participant suitability.  Do you think that including a Camel bean ID in
>> > the url (and a corresponding bean in the registry) for the Predicate
>> would
>> > be a good approach?
>> >
>>
>> Yes we could allow both kind, eg the user can send the java object and
>> have full control from java.
>>
>> Then in the uri, you can have a filter parameter of type predicate.
>> Then in the uri you can refer to a bean with the #bean:myFilter
>> syntax.
>> If you think that a predicate based on the simple language makes
>> sense, then we could also use that via the uri
>>
>> filter=${body} > 100
>>
>> The file component has some option that allows this, but lets fight
>> one battle at a time, and just get a #bean:xxx syntax to work first.
>>
>>
>> But before doing all of this, then I think the current PR can be merged
>> as is.
>>
>> Can you update the blog post date to today?
>>
>>
>>
>>
>> > On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >
>> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
>> > > >
>> > > > Hello.  I would like to add a little more to this conversation,
>> since you
>> > > > mentioned my reason for contributing this code.  My motivation to
>> add
>> > > this
>> > > > EIP component was because a couple of years ago, I read about the
>> dynamic
>> > > > router EIP within Camel, and I thought that it would be perfect for
>> what
>> > > I
>> > > > needed to do in my project at work.  It looked like my clients could
>> > > > register with the dynamic router processor, but further reading of
>> the
>> > > docs
>> > > > and my own use of it revealed that this was not how it was
>> implemented.
>> > > I
>> > > > was not able to use it for my use case, but I had to move on and
>> > > implement
>> > > > this behavior myself.
>> > > >
>> > > > Now that I had some time, I thought that I would contribute this
>> idea to
>> > > > Camel so that others would be able to use this particular type of
>> "glue"
>> > > > right out of the box that fits use cases that are like others in
>> camel,
>> > > but
>> > > > expanded in certain areas that include, but are probably not
>> limited to:
>> > > >
>> > > >    - the content-based router (choice), but the choices are fully
>> > > >    subscriber-initiated and do not need to be known at compile time
>> > > >    - the dynamic router (processor in Camel core), and I outlined
>> the
>> > > >    differences in the previous email, so no need to re-hash here
>> > > >    - the message filter, but instead of creating the filter at
>> compile
>> > > >    time, consumers provide their own filter at runtime
>> > > >    - the selective consumer, but turned the other way around:
>> instead of
>> > > >    sending messages to (potentially a list of) recipients, and
>> letting
>> > > them
>> > > >    all determine which messages to process or discard, this
>> component
>> > > allows a
>> > > >    consumer to subscribe with its filter so that the router can
>> handle
>> > > this
>> > > >    (centrally) and only send messages to the (first) appropriate
>> > > subscriber.
>> > > >    If we need a recipient list mode, that can easily be added so
>> that it
>> > > sends
>> > > >    to all matching recipients.
>> > > >    - the "To Dynamic" EIP, but the sender does not need to know
>> about
>> > > >    dynamic recipients, and variables do not have to be set
>> > > >
>> > >
>> > > That is a good break-down and perspective
>> > >
>> > > > I hope this shows how this contribution is not only "glue", but
>> that it
>> > > is
>> > > > useful glue that provides simplified routing for developers that
>> have use
>> > > > cases that overlap in the list of features above.  While you could
>> > > achieve
>> > > > anything in software by composing a solution of several different
>> pieces,
>> > > > and implementing the glue that helps them to work together and, in
>> this
>> > > > case, also implementing the runtime registration of recipients, this
>> > > > component ties these things together and makes it simple.  It is not
>> > > > intended to be its own messaging system, but to facilitate
>> messaging to,
>> > > > and from, other sources where the decision is truly runtime-based.
>> > > Indeed,
>> > > > you might have another messaging system that provides filtering,
>> etc, but
>> > > > this component introduces a new feature to provide this in a way
>> that is
>> > > > independent of other components/transports, and can, therefore, be
>> used
>> > > as
>> > > > a dynamic integration point between completely different messaging
>> > > systems.
>> > > >
>> > >
>> > > Yes I can see the validation, when you accept that it's not a
>> > > messaging system with client/server actors.
>> > > So when you say that you can subscribe/unsubscribe then it's not on
>> > > the same page as it would be with a JMS/Kafka client that subscribes
>> > > to a broker system.
>> > >
>> > > I wonder if you could research if you can make the subscription
>> > > simpler, as I think it's a little bit of a "hurdle" that Camel users
>> > > would
>> > > need to construct a java object to subscribe for basic subscription.
>> > >
>> > > You could have sub context for the action and channel, so if you just
>> > > want to subscribe you can send an empty message to
>> > >
>> > > dynamic-router:control/subscribe/my-channel?id=123
>> > >
>> > > You could also allow to auto-gen uuid for the subscription id, so if
>> > > id is omitted then one is returned
>> > >
>> > > String uid = requestBody(....)
>> > >
>> > > Anyway that is food for thoughts for improvements.
>> > >
>> > > What you have sent today as PR - lets review it. I can see its
>> > > usefulness and its potential if you continue to work on it.
>> > >
>> > >
>> > >
>> > >
>> > > > Thanks again,
>> > > > Steve
>> > > >
>> > > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
>> > > wrote:
>> > > >
>> > > > > Hi Steve
>> > > > >
>> > > > > We can see from your work that you have put a lot of effort and
>> > > > > devotion into this, with an example and blog post as well.
>> > > > >
>> > > > > However you say that the reason you wanted this was due to the
>> dynamic
>> > > > > pattern in the EIP book.
>> > > > >
>> > > > > The issue is that the EIP book is about messaging and integration
>> > > > > patterns and that these patterns
>> > > > > does not apply to all software projects.
>> > > > >
>> > > > > The dynamic pattern as in the EIP book is actuall a pattern in
>> > > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the
>> many of
>> > > > > them out there.
>> > > > > They all offer a way for clients to subscribe and unsubscribe to
>> > > > > topics (and or queues) and very often have filtering as well so a
>> > > > > client can say they the only want message that matches X criteria.
>> > > > >
>> > > > > In other words its a domain that is for a messaging system, and
>> this
>> > > > > gets quickly complex when you have distributed systems, and HA
>> with
>> > > > > failover, and now also with "the cloud", and even across multiple
>> > > > > cloud vendors with hybrid cloud.
>> > > > > Your implementation in Camel would be very limited in use-case as
>> its
>> > > > > a single context / in-memory only "queue".
>> > > > >
>> > > > >
>> > > > > If on the other hand there was a new messaging system (called
>> foobar),
>> > > > > and it was a well used system, then it would be worthwhile to
>> > > > > implement a camel component for such system.
>> > > > > In other words Camel is the glue to systems, but its "not a
>> "server"
>> > > > > system itself".
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com>
>> wrote:
>> > > > > >
>> > > > > > Hello.  I have sent a few messages here on this list about an
>> > > alternate
>> > > > > > Dynamic Router EIP component implementation that I have been
>> working
>> > > on.
>> > > > > > If anyone has some time, I would like to get more community
>> input and
>> > > > > > opinion on what I have done so far.  You can see the ticket
>> here:
>> > > > > >
>> > > > > > https://issues.apache.org/jira/browse/CAMEL-17154
>> > > > > >
>> > > > > > It contains a link to the component module on my fork of the
>> Camel
>> > > repo
>> > > > > (in
>> > > > > > the comments), and I have included a blog post draft ODT
>> attachment
>> > > that
>> > > > > > introduces this component, why I wanted to implement it, and
>> basic
>> > > > > > discussion on how to use it.
>> > > > > >
>> > > > > > If any of you would be kind enough to take a quick glance and
>> let me
>> > > know
>> > > > > > what you think, I would be quite grateful.
>> > > > > >
>> > > > > > Happy holidays, if you are celebrating.  Take care, and be well,
>> > > > > regardless.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Steve
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Claus Ibsen
>> > > > > -----------------
>> > > > > http://davsclaus.com @davsclaus
>> > > > > Camel in Action 2: https://www.manning.com/ibsen2
>> > > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Claus Ibsen
>> > > -----------------
>> > > http://davsclaus.com @davsclaus
>> > > Camel in Action 2: https://www.manning.com/ibsen2
>> > >
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Since this is my first contribution to one of my all-time favorite
libraries, this is pretty exciting for me.  I would be glad to update the
blog post immediately.  I will also add the things that we discussed with
regard to how this is a glue component, etc etc.  If you need me to change
(or shorten) it, let me know and I can turn that around quickly, as well.

On Tue, Jan 11, 2022 at 2:06 PM Claus Ibsen <cl...@gmail.com> wrote:

> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <st...@gmail.com> wrote:
> >
> > Thank you for the review and comments.  I completely agree with you that
> it
> > is cumbersome to require users to create a java object.  Your suggestion
> of
> > making the subscription URI-based is good, and I still need to figure out
> > how to provide the filter (Predicate) for evaluating exchanges for
> > participant suitability.  Do you think that including a Camel bean ID in
> > the url (and a corresponding bean in the registry) for the Predicate
> would
> > be a good approach?
> >
>
> Yes we could allow both kind, eg the user can send the java object and
> have full control from java.
>
> Then in the uri, you can have a filter parameter of type predicate.
> Then in the uri you can refer to a bean with the #bean:myFilter
> syntax.
> If you think that a predicate based on the simple language makes
> sense, then we could also use that via the uri
>
> filter=${body} > 100
>
> The file component has some option that allows this, but lets fight
> one battle at a time, and just get a #bean:xxx syntax to work first.
>
>
> But before doing all of this, then I think the current PR can be merged as
> is.
>
> Can you update the blog post date to today?
>
>
>
>
> > On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
> > > >
> > > > Hello.  I would like to add a little more to this conversation,
> since you
> > > > mentioned my reason for contributing this code.  My motivation to add
> > > this
> > > > EIP component was because a couple of years ago, I read about the
> dynamic
> > > > router EIP within Camel, and I thought that it would be perfect for
> what
> > > I
> > > > needed to do in my project at work.  It looked like my clients could
> > > > register with the dynamic router processor, but further reading of
> the
> > > docs
> > > > and my own use of it revealed that this was not how it was
> implemented.
> > > I
> > > > was not able to use it for my use case, but I had to move on and
> > > implement
> > > > this behavior myself.
> > > >
> > > > Now that I had some time, I thought that I would contribute this
> idea to
> > > > Camel so that others would be able to use this particular type of
> "glue"
> > > > right out of the box that fits use cases that are like others in
> camel,
> > > but
> > > > expanded in certain areas that include, but are probably not limited
> to:
> > > >
> > > >    - the content-based router (choice), but the choices are fully
> > > >    subscriber-initiated and do not need to be known at compile time
> > > >    - the dynamic router (processor in Camel core), and I outlined the
> > > >    differences in the previous email, so no need to re-hash here
> > > >    - the message filter, but instead of creating the filter at
> compile
> > > >    time, consumers provide their own filter at runtime
> > > >    - the selective consumer, but turned the other way around:
> instead of
> > > >    sending messages to (potentially a list of) recipients, and
> letting
> > > them
> > > >    all determine which messages to process or discard, this component
> > > allows a
> > > >    consumer to subscribe with its filter so that the router can
> handle
> > > this
> > > >    (centrally) and only send messages to the (first) appropriate
> > > subscriber.
> > > >    If we need a recipient list mode, that can easily be added so
> that it
> > > sends
> > > >    to all matching recipients.
> > > >    - the "To Dynamic" EIP, but the sender does not need to know about
> > > >    dynamic recipients, and variables do not have to be set
> > > >
> > >
> > > That is a good break-down and perspective
> > >
> > > > I hope this shows how this contribution is not only "glue", but that
> it
> > > is
> > > > useful glue that provides simplified routing for developers that
> have use
> > > > cases that overlap in the list of features above.  While you could
> > > achieve
> > > > anything in software by composing a solution of several different
> pieces,
> > > > and implementing the glue that helps them to work together and, in
> this
> > > > case, also implementing the runtime registration of recipients, this
> > > > component ties these things together and makes it simple.  It is not
> > > > intended to be its own messaging system, but to facilitate messaging
> to,
> > > > and from, other sources where the decision is truly runtime-based.
> > > Indeed,
> > > > you might have another messaging system that provides filtering,
> etc, but
> > > > this component introduces a new feature to provide this in a way
> that is
> > > > independent of other components/transports, and can, therefore, be
> used
> > > as
> > > > a dynamic integration point between completely different messaging
> > > systems.
> > > >
> > >
> > > Yes I can see the validation, when you accept that it's not a
> > > messaging system with client/server actors.
> > > So when you say that you can subscribe/unsubscribe then it's not on
> > > the same page as it would be with a JMS/Kafka client that subscribes
> > > to a broker system.
> > >
> > > I wonder if you could research if you can make the subscription
> > > simpler, as I think it's a little bit of a "hurdle" that Camel users
> > > would
> > > need to construct a java object to subscribe for basic subscription.
> > >
> > > You could have sub context for the action and channel, so if you just
> > > want to subscribe you can send an empty message to
> > >
> > > dynamic-router:control/subscribe/my-channel?id=123
> > >
> > > You could also allow to auto-gen uuid for the subscription id, so if
> > > id is omitted then one is returned
> > >
> > > String uid = requestBody(....)
> > >
> > > Anyway that is food for thoughts for improvements.
> > >
> > > What you have sent today as PR - lets review it. I can see its
> > > usefulness and its potential if you continue to work on it.
> > >
> > >
> > >
> > >
> > > > Thanks again,
> > > > Steve
> > > >
> > > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
> > > wrote:
> > > >
> > > > > Hi Steve
> > > > >
> > > > > We can see from your work that you have put a lot of effort and
> > > > > devotion into this, with an example and blog post as well.
> > > > >
> > > > > However you say that the reason you wanted this was due to the
> dynamic
> > > > > pattern in the EIP book.
> > > > >
> > > > > The issue is that the EIP book is about messaging and integration
> > > > > patterns and that these patterns
> > > > > does not apply to all software projects.
> > > > >
> > > > > The dynamic pattern as in the EIP book is actuall a pattern in
> > > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many
> of
> > > > > them out there.
> > > > > They all offer a way for clients to subscribe and unsubscribe to
> > > > > topics (and or queues) and very often have filtering as well so a
> > > > > client can say they the only want message that matches X criteria.
> > > > >
> > > > > In other words its a domain that is for a messaging system, and
> this
> > > > > gets quickly complex when you have distributed systems, and HA with
> > > > > failover, and now also with "the cloud", and even across multiple
> > > > > cloud vendors with hybrid cloud.
> > > > > Your implementation in Camel would be very limited in use-case as
> its
> > > > > a single context / in-memory only "queue".
> > > > >
> > > > >
> > > > > If on the other hand there was a new messaging system (called
> foobar),
> > > > > and it was a well used system, then it would be worthwhile to
> > > > > implement a camel component for such system.
> > > > > In other words Camel is the glue to systems, but its "not a
> "server"
> > > > > system itself".
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com>
> wrote:
> > > > > >
> > > > > > Hello.  I have sent a few messages here on this list about an
> > > alternate
> > > > > > Dynamic Router EIP component implementation that I have been
> working
> > > on.
> > > > > > If anyone has some time, I would like to get more community
> input and
> > > > > > opinion on what I have done so far.  You can see the ticket here:
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/CAMEL-17154
> > > > > >
> > > > > > It contains a link to the component module on my fork of the
> Camel
> > > repo
> > > > > (in
> > > > > > the comments), and I have included a blog post draft ODT
> attachment
> > > that
> > > > > > introduces this component, why I wanted to implement it, and
> basic
> > > > > > discussion on how to use it.
> > > > > >
> > > > > > If any of you would be kind enough to take a quick glance and
> let me
> > > know
> > > > > > what you think, I would be quite grateful.
> > > > > >
> > > > > > Happy holidays, if you are celebrating.  Take care, and be well,
> > > > > regardless.
> > > > > >
> > > > > > Thanks,
> > > > > > Steve
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Claus Ibsen
> > > > > -----------------
> > > > > http://davsclaus.com @davsclaus
> > > > > Camel in Action 2: https://www.manning.com/ibsen2
> > > > >
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Claus Ibsen <cl...@gmail.com>.

On Tue, Jan 11, 2022 at 7:13 PM Steve973 <st...@gmail.com> wrote:
>
> Thank you for the review and comments.  I completely agree with you that it
> is cumbersome to require users to create a java object.  Your suggestion of
> making the subscription URI-based is good, and I still need to figure out
> how to provide the filter (Predicate) for evaluating exchanges for
> participant suitability.  Do you think that including a Camel bean ID in
> the url (and a corresponding bean in the registry) for the Predicate would
> be a good approach?
>

Yes we could allow both kind, eg the user can send the java object and
have full control from java.

Then in the uri, you can have a filter parameter of type predicate.
Then in the uri you can refer to a bean with the #bean:myFilter
syntax.
If you think that a predicate based on the simple language makes
sense, then we could also use that via the uri

filter=${body} > 100

The file component has some option that allows this, but lets fight
one battle at a time, and just get a #bean:xxx syntax to work first.


But before doing all of this, then I think the current PR can be merged as is.

Can you update the blog post date to today?




> On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
> > >
> > > Hello.  I would like to add a little more to this conversation, since you
> > > mentioned my reason for contributing this code.  My motivation to add
> > this
> > > EIP component was because a couple of years ago, I read about the dynamic
> > > router EIP within Camel, and I thought that it would be perfect for what
> > I
> > > needed to do in my project at work.  It looked like my clients could
> > > register with the dynamic router processor, but further reading of the
> > docs
> > > and my own use of it revealed that this was not how it was implemented.
> > I
> > > was not able to use it for my use case, but I had to move on and
> > implement
> > > this behavior myself.
> > >
> > > Now that I had some time, I thought that I would contribute this idea to
> > > Camel so that others would be able to use this particular type of "glue"
> > > right out of the box that fits use cases that are like others in camel,
> > but
> > > expanded in certain areas that include, but are probably not limited to:
> > >
> > >    - the content-based router (choice), but the choices are fully
> > >    subscriber-initiated and do not need to be known at compile time
> > >    - the dynamic router (processor in Camel core), and I outlined the
> > >    differences in the previous email, so no need to re-hash here
> > >    - the message filter, but instead of creating the filter at compile
> > >    time, consumers provide their own filter at runtime
> > >    - the selective consumer, but turned the other way around: instead of
> > >    sending messages to (potentially a list of) recipients, and letting
> > them
> > >    all determine which messages to process or discard, this component
> > allows a
> > >    consumer to subscribe with its filter so that the router can handle
> > this
> > >    (centrally) and only send messages to the (first) appropriate
> > subscriber.
> > >    If we need a recipient list mode, that can easily be added so that it
> > sends
> > >    to all matching recipients.
> > >    - the "To Dynamic" EIP, but the sender does not need to know about
> > >    dynamic recipients, and variables do not have to be set
> > >
> >
> > That is a good break-down and perspective
> >
> > > I hope this shows how this contribution is not only "glue", but that it
> > is
> > > useful glue that provides simplified routing for developers that have use
> > > cases that overlap in the list of features above.  While you could
> > achieve
> > > anything in software by composing a solution of several different pieces,
> > > and implementing the glue that helps them to work together and, in this
> > > case, also implementing the runtime registration of recipients, this
> > > component ties these things together and makes it simple.  It is not
> > > intended to be its own messaging system, but to facilitate messaging to,
> > > and from, other sources where the decision is truly runtime-based.
> > Indeed,
> > > you might have another messaging system that provides filtering, etc, but
> > > this component introduces a new feature to provide this in a way that is
> > > independent of other components/transports, and can, therefore, be used
> > as
> > > a dynamic integration point between completely different messaging
> > systems.
> > >
> >
> > Yes I can see the validation, when you accept that it's not a
> > messaging system with client/server actors.
> > So when you say that you can subscribe/unsubscribe then it's not on
> > the same page as it would be with a JMS/Kafka client that subscribes
> > to a broker system.
> >
> > I wonder if you could research if you can make the subscription
> > simpler, as I think it's a little bit of a "hurdle" that Camel users
> > would
> > need to construct a java object to subscribe for basic subscription.
> >
> > You could have sub context for the action and channel, so if you just
> > want to subscribe you can send an empty message to
> >
> > dynamic-router:control/subscribe/my-channel?id=123
> >
> > You could also allow to auto-gen uuid for the subscription id, so if
> > id is omitted then one is returned
> >
> > String uid = requestBody(....)
> >
> > Anyway that is food for thoughts for improvements.
> >
> > What you have sent today as PR - lets review it. I can see its
> > usefulness and its potential if you continue to work on it.
> >
> >
> >
> >
> > > Thanks again,
> > > Steve
> > >
> > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
> > wrote:
> > >
> > > > Hi Steve
> > > >
> > > > We can see from your work that you have put a lot of effort and
> > > > devotion into this, with an example and blog post as well.
> > > >
> > > > However you say that the reason you wanted this was due to the dynamic
> > > > pattern in the EIP book.
> > > >
> > > > The issue is that the EIP book is about messaging and integration
> > > > patterns and that these patterns
> > > > does not apply to all software projects.
> > > >
> > > > The dynamic pattern as in the EIP book is actuall a pattern in
> > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> > > > them out there.
> > > > They all offer a way for clients to subscribe and unsubscribe to
> > > > topics (and or queues) and very often have filtering as well so a
> > > > client can say they the only want message that matches X criteria.
> > > >
> > > > In other words its a domain that is for a messaging system, and this
> > > > gets quickly complex when you have distributed systems, and HA with
> > > > failover, and now also with "the cloud", and even across multiple
> > > > cloud vendors with hybrid cloud.
> > > > Your implementation in Camel would be very limited in use-case as its
> > > > a single context / in-memory only "queue".
> > > >
> > > >
> > > > If on the other hand there was a new messaging system (called foobar),
> > > > and it was a well used system, then it would be worthwhile to
> > > > implement a camel component for such system.
> > > > In other words Camel is the glue to systems, but its "not a "server"
> > > > system itself".
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> > > > >
> > > > > Hello.  I have sent a few messages here on this list about an
> > alternate
> > > > > Dynamic Router EIP component implementation that I have been working
> > on.
> > > > > If anyone has some time, I would like to get more community input and
> > > > > opinion on what I have done so far.  You can see the ticket here:
> > > > >
> > > > > https://issues.apache.org/jira/browse/CAMEL-17154
> > > > >
> > > > > It contains a link to the component module on my fork of the Camel
> > repo
> > > > (in
> > > > > the comments), and I have included a blog post draft ODT attachment
> > that
> > > > > introduces this component, why I wanted to implement it, and basic
> > > > > discussion on how to use it.
> > > > >
> > > > > If any of you would be kind enough to take a quick glance and let me
> > know
> > > > > what you think, I would be quite grateful.
> > > > >
> > > > > Happy holidays, if you are celebrating.  Take care, and be well,
> > > > regardless.
> > > > >
> > > > > Thanks,
> > > > > Steve
> > > >
> > > >
> > > >
> > > > --
> > > > Claus Ibsen
> > > > -----------------
> > > > http://davsclaus.com @davsclaus
> > > > Camel in Action 2: https://www.manning.com/ibsen2
> > > >
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Thank you for the review and comments.  I completely agree with you that it
is cumbersome to require users to create a java object.  Your suggestion of
making the subscription URI-based is good, and I still need to figure out
how to provide the filter (Predicate) for evaluating exchanges for
participant suitability.  Do you think that including a Camel bean ID in
the url (and a corresponding bean in the registry) for the Predicate would
be a good approach?

On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com> wrote:

> On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
> >
> > Hello.  I would like to add a little more to this conversation, since you
> > mentioned my reason for contributing this code.  My motivation to add
> this
> > EIP component was because a couple of years ago, I read about the dynamic
> > router EIP within Camel, and I thought that it would be perfect for what
> I
> > needed to do in my project at work.  It looked like my clients could
> > register with the dynamic router processor, but further reading of the
> docs
> > and my own use of it revealed that this was not how it was implemented.
> I
> > was not able to use it for my use case, but I had to move on and
> implement
> > this behavior myself.
> >
> > Now that I had some time, I thought that I would contribute this idea to
> > Camel so that others would be able to use this particular type of "glue"
> > right out of the box that fits use cases that are like others in camel,
> but
> > expanded in certain areas that include, but are probably not limited to:
> >
> >    - the content-based router (choice), but the choices are fully
> >    subscriber-initiated and do not need to be known at compile time
> >    - the dynamic router (processor in Camel core), and I outlined the
> >    differences in the previous email, so no need to re-hash here
> >    - the message filter, but instead of creating the filter at compile
> >    time, consumers provide their own filter at runtime
> >    - the selective consumer, but turned the other way around: instead of
> >    sending messages to (potentially a list of) recipients, and letting
> them
> >    all determine which messages to process or discard, this component
> allows a
> >    consumer to subscribe with its filter so that the router can handle
> this
> >    (centrally) and only send messages to the (first) appropriate
> subscriber.
> >    If we need a recipient list mode, that can easily be added so that it
> sends
> >    to all matching recipients.
> >    - the "To Dynamic" EIP, but the sender does not need to know about
> >    dynamic recipients, and variables do not have to be set
> >
>
> That is a good break-down and perspective
>
> > I hope this shows how this contribution is not only "glue", but that it
> is
> > useful glue that provides simplified routing for developers that have use
> > cases that overlap in the list of features above.  While you could
> achieve
> > anything in software by composing a solution of several different pieces,
> > and implementing the glue that helps them to work together and, in this
> > case, also implementing the runtime registration of recipients, this
> > component ties these things together and makes it simple.  It is not
> > intended to be its own messaging system, but to facilitate messaging to,
> > and from, other sources where the decision is truly runtime-based.
> Indeed,
> > you might have another messaging system that provides filtering, etc, but
> > this component introduces a new feature to provide this in a way that is
> > independent of other components/transports, and can, therefore, be used
> as
> > a dynamic integration point between completely different messaging
> systems.
> >
>
> Yes I can see the validation, when you accept that it's not a
> messaging system with client/server actors.
> So when you say that you can subscribe/unsubscribe then it's not on
> the same page as it would be with a JMS/Kafka client that subscribes
> to a broker system.
>
> I wonder if you could research if you can make the subscription
> simpler, as I think it's a little bit of a "hurdle" that Camel users
> would
> need to construct a java object to subscribe for basic subscription.
>
> You could have sub context for the action and channel, so if you just
> want to subscribe you can send an empty message to
>
> dynamic-router:control/subscribe/my-channel?id=123
>
> You could also allow to auto-gen uuid for the subscription id, so if
> id is omitted then one is returned
>
> String uid = requestBody(....)
>
> Anyway that is food for thoughts for improvements.
>
> What you have sent today as PR - lets review it. I can see its
> usefulness and its potential if you continue to work on it.
>
>
>
>
> > Thanks again,
> > Steve
> >
> > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> > > Hi Steve
> > >
> > > We can see from your work that you have put a lot of effort and
> > > devotion into this, with an example and blog post as well.
> > >
> > > However you say that the reason you wanted this was due to the dynamic
> > > pattern in the EIP book.
> > >
> > > The issue is that the EIP book is about messaging and integration
> > > patterns and that these patterns
> > > does not apply to all software projects.
> > >
> > > The dynamic pattern as in the EIP book is actuall a pattern in
> > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> > > them out there.
> > > They all offer a way for clients to subscribe and unsubscribe to
> > > topics (and or queues) and very often have filtering as well so a
> > > client can say they the only want message that matches X criteria.
> > >
> > > In other words its a domain that is for a messaging system, and this
> > > gets quickly complex when you have distributed systems, and HA with
> > > failover, and now also with "the cloud", and even across multiple
> > > cloud vendors with hybrid cloud.
> > > Your implementation in Camel would be very limited in use-case as its
> > > a single context / in-memory only "queue".
> > >
> > >
> > > If on the other hand there was a new messaging system (called foobar),
> > > and it was a well used system, then it would be worthwhile to
> > > implement a camel component for such system.
> > > In other words Camel is the glue to systems, but its "not a "server"
> > > system itself".
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> > > >
> > > > Hello.  I have sent a few messages here on this list about an
> alternate
> > > > Dynamic Router EIP component implementation that I have been working
> on.
> > > > If anyone has some time, I would like to get more community input and
> > > > opinion on what I have done so far.  You can see the ticket here:
> > > >
> > > > https://issues.apache.org/jira/browse/CAMEL-17154
> > > >
> > > > It contains a link to the component module on my fork of the Camel
> repo
> > > (in
> > > > the comments), and I have included a blog post draft ODT attachment
> that
> > > > introduces this component, why I wanted to implement it, and basic
> > > > discussion on how to use it.
> > > >
> > > > If any of you would be kind enough to take a quick glance and let me
> know
> > > > what you think, I would be quite grateful.
> > > >
> > > > Happy holidays, if you are celebrating.  Take care, and be well,
> > > regardless.
> > > >
> > > > Thanks,
> > > > Steve
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Hi, Claus.  I have created a ticket to simplify the control channel
messages for the Dynamic Router EIP component:
https://issues.apache.org/jira/browse/CAMEL-17500

When you have a chance, please have a look and let me know if this is
complete enough for the next update to the component.

Thanks,
Steve

On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <cl...@gmail.com> wrote:

> On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
> >
> > Hello.  I would like to add a little more to this conversation, since you
> > mentioned my reason for contributing this code.  My motivation to add
> this
> > EIP component was because a couple of years ago, I read about the dynamic
> > router EIP within Camel, and I thought that it would be perfect for what
> I
> > needed to do in my project at work.  It looked like my clients could
> > register with the dynamic router processor, but further reading of the
> docs
> > and my own use of it revealed that this was not how it was implemented.
> I
> > was not able to use it for my use case, but I had to move on and
> implement
> > this behavior myself.
> >
> > Now that I had some time, I thought that I would contribute this idea to
> > Camel so that others would be able to use this particular type of "glue"
> > right out of the box that fits use cases that are like others in camel,
> but
> > expanded in certain areas that include, but are probably not limited to:
> >
> >    - the content-based router (choice), but the choices are fully
> >    subscriber-initiated and do not need to be known at compile time
> >    - the dynamic router (processor in Camel core), and I outlined the
> >    differences in the previous email, so no need to re-hash here
> >    - the message filter, but instead of creating the filter at compile
> >    time, consumers provide their own filter at runtime
> >    - the selective consumer, but turned the other way around: instead of
> >    sending messages to (potentially a list of) recipients, and letting
> them
> >    all determine which messages to process or discard, this component
> allows a
> >    consumer to subscribe with its filter so that the router can handle
> this
> >    (centrally) and only send messages to the (first) appropriate
> subscriber.
> >    If we need a recipient list mode, that can easily be added so that it
> sends
> >    to all matching recipients.
> >    - the "To Dynamic" EIP, but the sender does not need to know about
> >    dynamic recipients, and variables do not have to be set
> >
>
> That is a good break-down and perspective
>
> > I hope this shows how this contribution is not only "glue", but that it
> is
> > useful glue that provides simplified routing for developers that have use
> > cases that overlap in the list of features above.  While you could
> achieve
> > anything in software by composing a solution of several different pieces,
> > and implementing the glue that helps them to work together and, in this
> > case, also implementing the runtime registration of recipients, this
> > component ties these things together and makes it simple.  It is not
> > intended to be its own messaging system, but to facilitate messaging to,
> > and from, other sources where the decision is truly runtime-based.
> Indeed,
> > you might have another messaging system that provides filtering, etc, but
> > this component introduces a new feature to provide this in a way that is
> > independent of other components/transports, and can, therefore, be used
> as
> > a dynamic integration point between completely different messaging
> systems.
> >
>
> Yes I can see the validation, when you accept that it's not a
> messaging system with client/server actors.
> So when you say that you can subscribe/unsubscribe then it's not on
> the same page as it would be with a JMS/Kafka client that subscribes
> to a broker system.
>
> I wonder if you could research if you can make the subscription
> simpler, as I think it's a little bit of a "hurdle" that Camel users
> would
> need to construct a java object to subscribe for basic subscription.
>
> You could have sub context for the action and channel, so if you just
> want to subscribe you can send an empty message to
>
> dynamic-router:control/subscribe/my-channel?id=123
>
> You could also allow to auto-gen uuid for the subscription id, so if
> id is omitted then one is returned
>
> String uid = requestBody(....)
>
> Anyway that is food for thoughts for improvements.
>
> What you have sent today as PR - lets review it. I can see its
> usefulness and its potential if you continue to work on it.
>
>
>
>
> > Thanks again,
> > Steve
> >
> > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> > > Hi Steve
> > >
> > > We can see from your work that you have put a lot of effort and
> > > devotion into this, with an example and blog post as well.
> > >
> > > However you say that the reason you wanted this was due to the dynamic
> > > pattern in the EIP book.
> > >
> > > The issue is that the EIP book is about messaging and integration
> > > patterns and that these patterns
> > > does not apply to all software projects.
> > >
> > > The dynamic pattern as in the EIP book is actuall a pattern in
> > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> > > them out there.
> > > They all offer a way for clients to subscribe and unsubscribe to
> > > topics (and or queues) and very often have filtering as well so a
> > > client can say they the only want message that matches X criteria.
> > >
> > > In other words its a domain that is for a messaging system, and this
> > > gets quickly complex when you have distributed systems, and HA with
> > > failover, and now also with "the cloud", and even across multiple
> > > cloud vendors with hybrid cloud.
> > > Your implementation in Camel would be very limited in use-case as its
> > > a single context / in-memory only "queue".
> > >
> > >
> > > If on the other hand there was a new messaging system (called foobar),
> > > and it was a well used system, then it would be worthwhile to
> > > implement a camel component for such system.
> > > In other words Camel is the glue to systems, but its "not a "server"
> > > system itself".
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> > > >
> > > > Hello.  I have sent a few messages here on this list about an
> alternate
> > > > Dynamic Router EIP component implementation that I have been working
> on.
> > > > If anyone has some time, I would like to get more community input and
> > > > opinion on what I have done so far.  You can see the ticket here:
> > > >
> > > > https://issues.apache.org/jira/browse/CAMEL-17154
> > > >
> > > > It contains a link to the component module on my fork of the Camel
> repo
> > > (in
> > > > the comments), and I have included a blog post draft ODT attachment
> that
> > > > introduces this component, why I wanted to implement it, and basic
> > > > discussion on how to use it.
> > > >
> > > > If any of you would be kind enough to take a quick glance and let me
> know
> > > > what you think, I would be quite grateful.
> > > >
> > > > Happy holidays, if you are celebrating.  Take care, and be well,
> > > regardless.
> > > >
> > > > Thanks,
> > > > Steve
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Claus Ibsen <cl...@gmail.com>.

On Sat, Jan 8, 2022 at 4:09 PM Steve973 <st...@gmail.com> wrote:
>
> Hello.  I would like to add a little more to this conversation, since you
> mentioned my reason for contributing this code.  My motivation to add this
> EIP component was because a couple of years ago, I read about the dynamic
> router EIP within Camel, and I thought that it would be perfect for what I
> needed to do in my project at work.  It looked like my clients could
> register with the dynamic router processor, but further reading of the docs
> and my own use of it revealed that this was not how it was implemented.  I
> was not able to use it for my use case, but I had to move on and implement
> this behavior myself.
>
> Now that I had some time, I thought that I would contribute this idea to
> Camel so that others would be able to use this particular type of "glue"
> right out of the box that fits use cases that are like others in camel, but
> expanded in certain areas that include, but are probably not limited to:
>
>    - the content-based router (choice), but the choices are fully
>    subscriber-initiated and do not need to be known at compile time
>    - the dynamic router (processor in Camel core), and I outlined the
>    differences in the previous email, so no need to re-hash here
>    - the message filter, but instead of creating the filter at compile
>    time, consumers provide their own filter at runtime
>    - the selective consumer, but turned the other way around: instead of
>    sending messages to (potentially a list of) recipients, and letting them
>    all determine which messages to process or discard, this component allows a
>    consumer to subscribe with its filter so that the router can handle this
>    (centrally) and only send messages to the (first) appropriate subscriber.
>    If we need a recipient list mode, that can easily be added so that it sends
>    to all matching recipients.
>    - the "To Dynamic" EIP, but the sender does not need to know about
>    dynamic recipients, and variables do not have to be set
>

That is a good break-down and perspective

> I hope this shows how this contribution is not only "glue", but that it is
> useful glue that provides simplified routing for developers that have use
> cases that overlap in the list of features above.  While you could achieve
> anything in software by composing a solution of several different pieces,
> and implementing the glue that helps them to work together and, in this
> case, also implementing the runtime registration of recipients, this
> component ties these things together and makes it simple.  It is not
> intended to be its own messaging system, but to facilitate messaging to,
> and from, other sources where the decision is truly runtime-based.  Indeed,
> you might have another messaging system that provides filtering, etc, but
> this component introduces a new feature to provide this in a way that is
> independent of other components/transports, and can, therefore, be used as
> a dynamic integration point between completely different messaging systems.
>

Yes I can see the validation, when you accept that it's not a
messaging system with client/server actors.
So when you say that you can subscribe/unsubscribe then it's not on
the same page as it would be with a JMS/Kafka client that subscribes
to a broker system.

I wonder if you could research if you can make the subscription
simpler, as I think it's a little bit of a "hurdle" that Camel users
would
need to construct a java object to subscribe for basic subscription.

You could have sub context for the action and channel, so if you just
want to subscribe you can send an empty message to

dynamic-router:control/subscribe/my-channel?id=123

You could also allow to auto-gen uuid for the subscription id, so if
id is omitted then one is returned

String uid = requestBody(....)

Anyway that is food for thoughts for improvements.

What you have sent today as PR - lets review it. I can see its
usefulness and its potential if you continue to work on it.




> Thanks again,
> Steve
>
> On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> > Hi Steve
> >
> > We can see from your work that you have put a lot of effort and
> > devotion into this, with an example and blog post as well.
> >
> > However you say that the reason you wanted this was due to the dynamic
> > pattern in the EIP book.
> >
> > The issue is that the EIP book is about messaging and integration
> > patterns and that these patterns
> > does not apply to all software projects.
> >
> > The dynamic pattern as in the EIP book is actuall a pattern in
> > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> > them out there.
> > They all offer a way for clients to subscribe and unsubscribe to
> > topics (and or queues) and very often have filtering as well so a
> > client can say they the only want message that matches X criteria.
> >
> > In other words its a domain that is for a messaging system, and this
> > gets quickly complex when you have distributed systems, and HA with
> > failover, and now also with "the cloud", and even across multiple
> > cloud vendors with hybrid cloud.
> > Your implementation in Camel would be very limited in use-case as its
> > a single context / in-memory only "queue".
> >
> >
> > If on the other hand there was a new messaging system (called foobar),
> > and it was a well used system, then it would be worthwhile to
> > implement a camel component for such system.
> > In other words Camel is the glue to systems, but its "not a "server"
> > system itself".
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> > >
> > > Hello.  I have sent a few messages here on this list about an alternate
> > > Dynamic Router EIP component implementation that I have been working on.
> > > If anyone has some time, I would like to get more community input and
> > > opinion on what I have done so far.  You can see the ticket here:
> > >
> > > https://issues.apache.org/jira/browse/CAMEL-17154
> > >
> > > It contains a link to the component module on my fork of the Camel repo
> > (in
> > > the comments), and I have included a blog post draft ODT attachment that
> > > introduces this component, why I wanted to implement it, and basic
> > > discussion on how to use it.
> > >
> > > If any of you would be kind enough to take a quick glance and let me know
> > > what you think, I would be quite grateful.
> > >
> > > Happy holidays, if you are celebrating.  Take care, and be well,
> > regardless.
> > >
> > > Thanks,
> > > Steve
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Hi, Claus.  I am just checking in to see if expanding on my rationale for
the component helped at all, and if you have any additional thoughts.  In
short, is it ok for a component to be "glue"?

Thanks,
Steve

On Sat, Jan 8, 2022 at 10:09 AM Steve973 <st...@gmail.com> wrote:

> Hello.  I would like to add a little more to this conversation, since you
> mentioned my reason for contributing this code.  My motivation to add this
> EIP component was because a couple of years ago, I read about the dynamic
> router EIP within Camel, and I thought that it would be perfect for what I
> needed to do in my project at work.  It looked like my clients could
> register with the dynamic router processor, but further reading of the docs
> and my own use of it revealed that this was not how it was implemented.  I
> was not able to use it for my use case, but I had to move on and implement
> this behavior myself.
>
> Now that I had some time, I thought that I would contribute this idea to
> Camel so that others would be able to use this particular type of "glue"
> right out of the box that fits use cases that are like others in camel, but
> expanded in certain areas that include, but are probably not limited to:
>
>    - the content-based router (choice), but the choices are fully
>    subscriber-initiated and do not need to be known at compile time
>    - the dynamic router (processor in Camel core), and I outlined the
>    differences in the previous email, so no need to re-hash here
>    - the message filter, but instead of creating the filter at compile
>    time, consumers provide their own filter at runtime
>    - the selective consumer, but turned the other way around: instead of
>    sending messages to (potentially a list of) recipients, and letting them
>    all determine which messages to process or discard, this component allows a
>    consumer to subscribe with its filter so that the router can handle this
>    (centrally) and only send messages to the (first) appropriate subscriber.
>    If we need a recipient list mode, that can easily be added so that it sends
>    to all matching recipients.
>    - the "To Dynamic" EIP, but the sender does not need to know about
>    dynamic recipients, and variables do not have to be set
>
> I hope this shows how this contribution is not only "glue", but that it is
> useful glue that provides simplified routing for developers that have use
> cases that overlap in the list of features above.  While you could achieve
> anything in software by composing a solution of several different pieces,
> and implementing the glue that helps them to work together and, in this
> case, also implementing the runtime registration of recipients, this
> component ties these things together and makes it simple.  It is not
> intended to be its own messaging system, but to facilitate messaging to,
> and from, other sources where the decision is truly runtime-based.  Indeed,
> you might have another messaging system that provides filtering, etc, but
> this component introduces a new feature to provide this in a way that is
> independent of other components/transports, and can, therefore, be used as
> a dynamic integration point between completely different messaging systems.
>
> Thanks again,
> Steve
>
> On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi Steve
>>
>> We can see from your work that you have put a lot of effort and
>> devotion into this, with an example and blog post as well.
>>
>> However you say that the reason you wanted this was due to the dynamic
>> pattern in the EIP book.
>>
>> The issue is that the EIP book is about messaging and integration
>> patterns and that these patterns
>> does not apply to all software projects.
>>
>> The dynamic pattern as in the EIP book is actuall a pattern in
>> messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
>> them out there.
>> They all offer a way for clients to subscribe and unsubscribe to
>> topics (and or queues) and very often have filtering as well so a
>> client can say they the only want message that matches X criteria.
>>
>> In other words its a domain that is for a messaging system, and this
>> gets quickly complex when you have distributed systems, and HA with
>> failover, and now also with "the cloud", and even across multiple
>> cloud vendors with hybrid cloud.
>> Your implementation in Camel would be very limited in use-case as its
>> a single context / in-memory only "queue".
>>
>>
>> If on the other hand there was a new messaging system (called foobar),
>> and it was a well used system, then it would be worthwhile to
>> implement a camel component for such system.
>> In other words Camel is the glue to systems, but its "not a "server"
>> system itself".
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
>> >
>> > Hello.  I have sent a few messages here on this list about an alternate
>> > Dynamic Router EIP component implementation that I have been working on.
>> > If anyone has some time, I would like to get more community input and
>> > opinion on what I have done so far.  You can see the ticket here:
>> >
>> > https://issues.apache.org/jira/browse/CAMEL-17154
>> >
>> > It contains a link to the component module on my fork of the Camel repo
>> (in
>> > the comments), and I have included a blog post draft ODT attachment that
>> > introduces this component, why I wanted to implement it, and basic
>> > discussion on how to use it.
>> >
>> > If any of you would be kind enough to take a quick glance and let me
>> know
>> > what you think, I would be quite grateful.
>> >
>> > Happy holidays, if you are celebrating.  Take care, and be well,
>> regardless.
>> >
>> > Thanks,
>> > Steve
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Steve973 <st...@gmail.com>.

Hello.  I would like to add a little more to this conversation, since you
mentioned my reason for contributing this code.  My motivation to add this
EIP component was because a couple of years ago, I read about the dynamic
router EIP within Camel, and I thought that it would be perfect for what I
needed to do in my project at work.  It looked like my clients could
register with the dynamic router processor, but further reading of the docs
and my own use of it revealed that this was not how it was implemented.  I
was not able to use it for my use case, but I had to move on and implement
this behavior myself.

Now that I had some time, I thought that I would contribute this idea to
Camel so that others would be able to use this particular type of "glue"
right out of the box that fits use cases that are like others in camel, but
expanded in certain areas that include, but are probably not limited to:

   - the content-based router (choice), but the choices are fully
   subscriber-initiated and do not need to be known at compile time
   - the dynamic router (processor in Camel core), and I outlined the
   differences in the previous email, so no need to re-hash here
   - the message filter, but instead of creating the filter at compile
   time, consumers provide their own filter at runtime
   - the selective consumer, but turned the other way around: instead of
   sending messages to (potentially a list of) recipients, and letting them
   all determine which messages to process or discard, this component allows a
   consumer to subscribe with its filter so that the router can handle this
   (centrally) and only send messages to the (first) appropriate subscriber.
   If we need a recipient list mode, that can easily be added so that it sends
   to all matching recipients.
   - the "To Dynamic" EIP, but the sender does not need to know about
   dynamic recipients, and variables do not have to be set

I hope this shows how this contribution is not only "glue", but that it is
useful glue that provides simplified routing for developers that have use
cases that overlap in the list of features above.  While you could achieve
anything in software by composing a solution of several different pieces,
and implementing the glue that helps them to work together and, in this
case, also implementing the runtime registration of recipients, this
component ties these things together and makes it simple.  It is not
intended to be its own messaging system, but to facilitate messaging to,
and from, other sources where the decision is truly runtime-based.  Indeed,
you might have another messaging system that provides filtering, etc, but
this component introduces a new feature to provide this in a way that is
independent of other components/transports, and can, therefore, be used as
a dynamic integration point between completely different messaging systems.

Thanks again,
Steve

On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:

> Hi Steve
>
> We can see from your work that you have put a lot of effort and
> devotion into this, with an example and blog post as well.
>
> However you say that the reason you wanted this was due to the dynamic
> pattern in the EIP book.
>
> The issue is that the EIP book is about messaging and integration
> patterns and that these patterns
> does not apply to all software projects.
>
> The dynamic pattern as in the EIP book is actuall a pattern in
> messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> them out there.
> They all offer a way for clients to subscribe and unsubscribe to
> topics (and or queues) and very often have filtering as well so a
> client can say they the only want message that matches X criteria.
>
> In other words its a domain that is for a messaging system, and this
> gets quickly complex when you have distributed systems, and HA with
> failover, and now also with "the cloud", and even across multiple
> cloud vendors with hybrid cloud.
> Your implementation in Camel would be very limited in use-case as its
> a single context / in-memory only "queue".
>
>
> If on the other hand there was a new messaging system (called foobar),
> and it was a well used system, then it would be worthwhile to
> implement a camel component for such system.
> In other words Camel is the glue to systems, but its "not a "server"
> system itself".
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> >
> > Hello.  I have sent a few messages here on this list about an alternate
> > Dynamic Router EIP component implementation that I have been working on.
> > If anyone has some time, I would like to get more community input and
> > opinion on what I have done so far.  You can see the ticket here:
> >
> > https://issues.apache.org/jira/browse/CAMEL-17154
> >
> > It contains a link to the component module on my fork of the Camel repo
> (in
> > the comments), and I have included a blog post draft ODT attachment that
> > introduces this component, why I wanted to implement it, and basic
> > discussion on how to use it.
> >
> > If any of you would be kind enough to take a quick glance and let me know
> > what you think, I would be quite grateful.
> >
> > Happy holidays, if you are celebrating.  Take care, and be well,
> regardless.
> >
> > Thanks,
> > Steve
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

Posted by Claus Ibsen <cl...@gmail.com>.

Hi Steve

We can see from your work that you have put a lot of effort and
devotion into this, with an example and blog post as well.

However you say that the reason you wanted this was due to the dynamic
pattern in the EIP book.

The issue is that the EIP book is about messaging and integration
patterns and that these patterns
does not apply to all software projects.

The dynamic pattern as in the EIP book is actuall a pattern in
messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
them out there.
They all offer a way for clients to subscribe and unsubscribe to
topics (and or queues) and very often have filtering as well so a
client can say they the only want message that matches X criteria.

In other words its a domain that is for a messaging system, and this
gets quickly complex when you have distributed systems, and HA with
failover, and now also with "the cloud", and even across multiple
cloud vendors with hybrid cloud.
Your implementation in Camel would be very limited in use-case as its
a single context / in-memory only "queue".

If on the other hand there was a new messaging system (called foobar),
and it was a well used system, then it would be worthwhile to
implement a camel component for such system.
In other words Camel is the glue to systems, but its "not a "server"
system itself".

On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
>
> Hello.  I have sent a few messages here on this list about an alternate
> Dynamic Router EIP component implementation that I have been working on.
> If anyone has some time, I would like to get more community input and
> opinion on what I have done so far.  You can see the ticket here:
>
> https://issues.apache.org/jira/browse/CAMEL-17154
>
> It contains a link to the component module on my fork of the Camel repo (in
> the comments), and I have included a blog post draft ODT attachment that
> introduces this component, why I wanted to implement it, and basic
> discussion on how to use it.
>
> If any of you would be kind enough to take a quick glance and let me know
> what you think, I would be quite grateful.
>
> Happy holidays, if you are celebrating.  Take care, and be well, regardless.
>
> Thanks,
> Steve

-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2