Hi If camel-knative is enriched with CE, then we could potentially make camel-jbang automatically include camel-knative and include CEs as well, to make it possible to simulate locally with that information as well.
On Thu, Feb 23, 2023 at 6:21 AM Mikael Koskinen <mijap...@gmail.com> wrote: > Hi, > > Ok, thanks for the detailed explanation. > > I was intrigued to find out that Camel-K contains the support for > transforming the messages into CloudEvents and the experimentation was > if I could somehow leverage that feature outside the Camel-K. But now > I wonder if I could just use the KNative component as it (I think) > seems to be one creating the CloudEvents.. > > Anyways, I really appreciate the response, thank you! > > Best regards, > Mikael > > ke 22. helmik. 2023 klo 16.03 Pasquale Congiusti > (pasquale.congiu...@gmail.com) kirjoitti: > > > > Hi Mikael, > > yes, there are important differences when running *any* Camel application > > (not only KameletBindings) via Camel JBang or via Kamel CLI. First of > all, > > in the first case you're running the application locally and you're using > > your local JVM to run it. The scaffolding and creation of the Maven > project > > is done by camel CLI and the execution is local using Camel-Main. When > you > > run via kamel, you're running your application remotely, building it on > the > > cluster (with a different mechanics of Camel JBang), preparing all > > Kubernetes configuration and finally running the runtime as a > Camel-Quarkus > > application. > > > > For your specific case, the local execution misses some important piece > > required to convert the messages in CloudEvents. Running it remotely (and > > also probably with a KNative profile) will do all the transformation > > required. That's the reason why you don't see the messages transformed > in a > > local execution. > > > > Cheers, > > Pasquale. > > > > On Wed, Feb 22, 2023 at 2:33 PM Mikael Koskinen <mijap...@gmail.com> > wrote: > > > > > Hi, > > > > > > I'm wondering if KameletBinding works differently if run through Camel > > > JBang vs running the binding using Camel-K. > > > > > > The documentation states that if I use http or https-endpoint as a > > > sink, I should receive a CloudEvent from the source but this doesn't > > > seem to be the case based on my testing using the Camel JBang. That's > > > why I'm wondering if there's a difference between Camel-K and the CLI > > > or if the documentation is missing a step. > > > > > > Here's the part from the documentation: > > > --- > > > the uri option is also conventionally used in Knative to specify a > > > non-kubernetes destination. To comply with the Knative specifications, > > > in case an "http" or "https" URI is used, Camel will send CloudEvents > > > to the destination. > > > --- > > > > > > To test this I created the following binding: > > > > > > apiVersion: camel.apache.org/v1alpha1 > > > kind: KameletBinding > > > metadata: > > > name: test-binding > > > spec: > > > source: > > > ref: > > > kind: Kamelet > > > apiVersion: camel.apache.org/v1alpha1 > > > name: file-watch-source > > > properties: > > > filePath: c:/temp/kamel > > > events: CREATE > > > sink: > > > uri: https://webhook.site/7e80a696-5d47-4a03-8507-1fe4e47cfec6 > > > > > > And used the CLI to run this: camel run hmm.yaml > > > > > > The binding itself works but instead of CloudEvents the sink is > > > receiving just the exchange body. > > > > > > Any ideas if there's a step missing? Thanks in advance. > > > > > > Best regards, > > > Mikael > > > > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
