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 <claus.ib...@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 <steve...@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 <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 > > >>> > > >> > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >