Hello Claus, thanks for the clarification! On Fri, Jul 9, 2021 at 9:42 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi > > The CAMEL-16757 is not really about loading routes (we can do that > already today with the routes loader and resource abstractions). > What it is about is to allow to separate your routes from route > configurations, and also allow such configurations to be easily > reusable. > Today you have either global vs route, but with this you can have > reusable route configurations you can easily on a per route choose to > refer to an existing configuration. > This allow DRY (dont repeat yourself) as otherwise users would have to > copy the same route configuration on their routes. > > Also the configuration can be loaded separated from the actual routes, > so you can have Camel expert users setup a common set of route > configurations and put that in a JAR. > And then novice Camel users can add the JAR and have it enabled out of > the box, or they can refer to the route configuration by a logical > name. > > Today you can't really do that, and you would have to put route > configuration and route together (or if you use Java you can do some > tricks with the xxxDefinition classes). > Also this is to make this unified across all the DSLs. So it's the > same way to do this. For example error handler (not onException) is > different in XML vs Java vs YAML etc. > > > > You have some great ideas for camel and jbang in your email. > I suggest to start a new mail thread on Camel DEV where we can discuss > this. > > > In the mean time take good care of the Camel wile I am on PTO ;) > > > > > On Thu, Jul 8, 2021 at 3:06 PM Otavio Rodolfo Piske > <angusyo...@gmail.com> wrote: > > > > Hello Claus, > > > > This looks very interesting! > > > > If I understand correctly, with this change, we'll be able to replace the > > usage of KameletMain in CAMEL-16612 [1] and then we can load all sorts of > > routes out of the box, without relying on or implementing different kinds > > of "Main". > > > > So, if my understanding is correct, then it will make it much easier to > > load them on Camel JBang as the new loader does the bulk of the work. > > > > In terms of ideas ... > > > > One scenario that I have been thinking of - but haven't fully matured > yet - > > is whether it's worth pursuing a type of "pipe into/out of shell" feature > > for CAMEL-16612. Specifically: whether we could modify Camel JBang so > that > > we could use it as part of shell scripts. For example: > > > > CamelJBang run /path/to/route.yaml | ... shell script stuff here (sed, > > grep, awk, etc) > > > > One challenge is that we need to find a way to flexibilize the end of the > > execution dynamically. Maybe even from the standard input ... so that > would > > behave similar to this: > > > > - echo "<some yaml with termination rule>" | CamelJBang run > > /path/to/route.yaml | ... shell script stuff here (sed, grep, awk, etc) > > > > or > > > > - CamelJBang run /path/to/route.yaml /path/to/termination.yaml | ... > shell > > script stuff here (sed, grep, awk, etc) > > > > With this, we might be able to offer a client that plugs everything to > > everything almost out of the box and is easily scriptable in shell. > > > > Obs.: enjoy your PTO! > > > > 1. https://github.com/apache/camel/pull/5770 > > > > Kind regards > > > > On Thu, Jul 8, 2021 at 2:12 PM Claus Ibsen <claus.ib...@gmail.com> > wrote: > > > > > Hi > > > > > > I am working on (branch on git with the ticket number) > > > https://issues.apache.org/jira/browse/CAMEL-16757 > > > > > > Its work in progress, but I got a prototype in a new example > > > > > > > https://github.com/apache/camel-examples/tree/main/examples/routes-configuration > > > > > > In this example we have routes in java, xml and yaml in the myroutes > > > folder. For Java you can of course also have it in src/main/java. > > > > > > But the point is to make this work for dynamic loaded routes (also > > > Java) and hence why its in the myroutes folder. > > > > > > These routes causes exceptions, and then we have global configured > > > error handling in separate source code, in the myerror folder. > > > > > > Those are also polyglot and you can define this in XML, YAML or Java > etc. > > > > > > There is more to work on but wanted to share the heads-up. > > > I will be on PTO 2 weeks from tomorrow afternoon. So will work on > > > finishing this later. > > > > > > The potential is also to allow users to define their global error > > > handler, route configurations, and you can put that into separate JAR > > > and just add as dependency. And then you can refer to these route > > > configurations from your routes or to use the global configured etc. > > > > > > Feedback is welcome, the work is "not set in stone". > > > > > > > > > > > > -- > > > Claus Ibsen > > > ----------------- > > > http://davsclaus.com @davsclaus > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > -- > > Otavio R. Piske > > http://orpiske.net > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Otavio R. Piske http://orpiske.net
