Yes both Kaoto and Karavan support Camel v4. Kaoto has a version picker where you can switch to the different Camel versions supported by this tool. Karavan is locked to a given Camel version - same version as its release number.

Yes thanks, you can use ENV variables for passwords or external configuration files, or security vaults, or k8s secrets, read values from database, and much more. This is just for a prototype using local docker compose.

Thanks yeah that is maybe a little bug - Ideally we should have "step into" and "step over" so you can debug and something just quickly skip over an entire split etc.

Yes I will try to create more often some videos - its a one-take shoot so dont expect me learning and spending too much time to be a pro video editor.

@@ClausIbsen sure, Thank you

Yeah its a goal to help learn integration by just focusing on that (and Camel) and not all the other stuff like Spring Boot / Quarkus / Kubernetes / Docker / Maven / Dependencies / Build pipelines and a lot more. Just build a prototype to get going and see for yourself how to integrate and work on the data. (better data mapping and data introspection is on the roadmaps)

@@ClausIbsen yes, makes sense

If you are using Windows then there was some trouble that we have fixed/improved in Camel 4.5 and the next 4.6 release. So upgrade and try again.

Thanks for the insights, Could you please share updated video? I am particularly interested in Camel K and best practices around it, For me 30 min is not long as it covered several topics, If possible maybe an overview video and an in depth video would be great 🙏

I want to use Apache camel with quarkus to replace ibm message broker where we need to integrate ibm mainframe on tcp connection , please advise is that right move or will have any problem ?

This example is up to date with latest Camel Quarkus release here: github.com/apache/camel-quarkus-examples/tree/main/http-log The video and what's done is 99% the same today. However indeed Camel v4 has since been released and new features and functionality keeps being added and improved, but that is for Camel in general. Also today I would also recommend taking a look at camel-jbang and what it can do to quickly try Camel without having to pick and learn Quarkus or Spring Boot first.

Yeah there is no single path to learn Camel (or anything for that matter), people need different ways to learn. For general Camel there are some online training courses (some require to pay). In terms of keeping up to date with Camel, eg if you are familing with Camel 2. And now get back and want to learn Camel 4, then the fundamentals is 99% the same. Its usually all the other stuff that changes - cloud, kubernetes, spring boot, quarkus, java, etc. Now we have camel-jbang that IMHO allows you to try and learn Camel without getting distracted by all the "other stuff". I would suggest to use this first. Then there is a ton of videos on youtube. However you may not always have time to watch all of them, but there are some great content now and then. I am afraid I dont have a lot of time to write a 3rd edition of the book, and all the hard work does not earn much $ so its hard to justifice to the familiy how much time I have to be "away" if doing this.

Glad you liked it!

I am trying run 'camel debug' in throws Cannot run program "camel": CreateProcess error=2, The system cannot find the file specified this error. I am using camel-jbang version 4.4.1, running in windows 11 machine. Any suggestion ? .. should raise an issue somewhere ?

Sorry I have no such plans. You can take a look at the zookeeper-master component and there is also some details in the Camel in Action 2nd ed book in the clustering chapter.

I can't find the 4.2 snapshot version. Is it available somewhere? I will present "why Camel has to be known" to my integration engineers colleagues. The clipboard reload would be so easy to demo Camel capabilities

snapshots are automatic published to ASF snapshat repo, and camel-jbang should be able to use it. After installing jbang, and because the reload change also requires to use latest camel-jbang CLI then you need to adjust the local file afterwards (not super easy). In ~/.jbang/cache/urls You have sub folders, and in one of these you can find CamelJBang.java, edit this file and change version from 4.1.0 to 4.2.0-SNAPSHOT for the camel version. Then you will use SNAPSHOT in both CLI and runtime. BTW you can change camel runtime version easily from CLI with camel version set Or when you run, eg camel run foo.yaml --camel-version=4.0.1 See the documentation on the website @@AntoineWils

This is what my local file has now //DEPS org.apache.camel:camel-bom:${camel.jbang.version:4.2.0-SNAPSHOT}@pom //DEPS org.apache.camel:camel-jbang-core:${camel.jbang.version:4.2.0-SNAPSHOT}

@@ClausIbsen thank you for the details. I will try this asap

​@@ClausIbsen I have the 4.2.0-SNAPSHOT installed and running. Thank you very much.

loom works fine

@@matheusrehbein4234 Thank you for the suggestion - I will try it

@@ClausIbsen Google meet should be able to record similarly. I use ms teams.

Sorry for the late reply. The example source is here: github.com/apache/camel-quarkus-examples/tree/main/http-log And the example is kept up to date with newer Camel Quarkus releases.

Did you finish reading the book, after 3 years you may have read all 900+ pages ;)

Yes native compiled graal also have GC settings you can set like regular Java.

It is currently only Java but XML can be added as we have the parser for that also. A big difference is that this tool is for development, eg during coding (not at runtime) hawtio is a monitoring tool that can dive into running JVMs and inspect and visualize details, and it has a Camel plugin so it can interrogate the running Camel to have it to output its running routes which hawtio then draw visually.

Kafka is for messaging .. Camel is an integration framework which uses Kafka to implement EIP , especially event driven messaging

Shoaib Khan its better to discuss such kind of question at the Camel community such as gitter chat og the mailing list

hello, did you get a reply for your issue ? thanks

@@wassimopencell7982 No we dropped the idea of Camel K as it doesn't fit with Enterprise requirements. We use plain old Apache camel and it just works perfectly.

@@ShoaibKhan_iamsrk Thanks !

@@ShoaibKhan_iamsrk yes standard Camel should be first choice. And today its innovating and evolving with camel-jbang, karavan, and much more.

Yeah Quarkus was front runner there. SB v3 is starting to have native support as well. However we at the ASF Camel don't have much time to also optimize Camel for SB native. Camel Quarkus has full time staff from Red Hat so it will always be leading.

Use a standard container and copy the runner into it. Once you've turned it in to native code, it doesn't need the JVM. It probably still needs glibc though. Of course, you can still use GraalVM in your containers for running jar files.

Yeah I am working on something for that I want to get polished and a lot more easier than currently. Native compiled requires to compile as linux executable and thats harder to do on Mac and Windows laptops. And Quarkus is IMHO not yet there with very slick and easy to use/do that. But as Daniel says if you get over the hurdle of getting a native binary compiled, then running that is just a matter of putting that into a docker image, and the base images from quarkus (ubi-minimal) is optimized for this.

@@ClausIbsen Yes on Mac am facing the similar challenge with native binary, and that too it took almost 30+ minutes to generate the native binary with GraalVM 20.0, 16 GB RAM, core i7 2.2 GHz. Though it looks promising for the runtime with Quarkus & GraalVM, but the compilation and build process has to speed up. Imagine we have 100+ microservices for integrations (with almost majority of camel components), was trying to start with migration to Quarkus but build process looks challenging especially for future releases and build pipeline will be stuck forever.

@@8bitcoder Isn't there a more layered approach?

@@RobertoFabrizi For a native runtime? No, I don't think so. For a Quarkus JAR based application, yes, you could use Docker layers (i.e. O/S, JVM, common libs, app JAR). It takes more planning, but it's totally doable.