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 <steve...@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 <steve...@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 <claus.ib...@gmail.com>
>> wrote:
>>
>>> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <steve...@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.ib...@gmail.com>
>>> wrote:
>>> >
>>> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <steve...@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.ib...@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 <steve...@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
>>>
>>
