See apache/camel-k#511

We can add a third endpoint to knative called events.

A user can write:

from('knative:events/chuck.norris')

To get all events of type chuck.norris.
The behavior will be:

• The operator creates a trigger on event type chuck.norris
• The component filters messages containing header Ce-Type equals to chuck.norris
• The component exposes the usual endpoint to receive cloud events

Some additional properties are required:

• brokerApiVersion: to change the api version of the broker (interpreted by the operator)
• brokerName: to change the name of the broker to use (by default there's only one called default)
• brokerKind cannot be changed as there's a single CRD at the moment

Additional filters can be put in the endpoint, e.g.:

from('knative:events/chuck.norris?ceAuthorName=Nicola')

ceAuthorName like filters can be dynamic and translate into an additional filter on both the trigger and the component on the header Ce-Author-Name.

Now that GraalJS is available we can use it in place of nashorn

Because of no main artifact defined. Disabled in current release (no need).

We should make sure they don't fail for nex.

File org/apache/camel/catalog/components/knative.json is missing for the knative component.

when camel 3 gets stable enough we should drop support for camel 2.x as maintaining support for both the version is becoming more and more complex as source of errors.

We need to create the source release artifact for the camel-k-runtime project.

Consider the following integration sending data to a channel:

from('timer:clock?period=3s')
	.setBody().constant("Hello World from Camel K")
	.setHeader('CamelCippaLippa').constant('42')
	.to('log:info?showHeaders=true')
	.to('knative:channel/messages')
	.to('log:info?showHeaders=true')
	.log('sent message to messages channel')

This is the output log:

2019-07-26 10:57:00.318 �[32mINFO �[m [Camel (camel-k) thread #2 - timer://clock] info - Exchange[ExchangePattern: InOnly, Headers: {CamelCippaLippa=42, firedTime=Fri Jul 26 10:57:00 UTC 2019}, BodyType: String, Body: Hello World from Camel K]
2019-07-26 10:57:00.323 �[32mINFO �[m [Camel Thread #3 - NettyClientTCPWorker] info - Exchange[ExchangePattern: InOnly, Headers: {CamelHttpResponseCode=202, CamelHttpResponseText=Accepted, Content-Length=0, Date=Fri, 26 Jul 2019 10:57:00 GMT}, BodyType: byte[], Body: ]
2019-07-26 10:57:00.323 �[32mINFO �[m [Camel Thread #3 - NettyClientTCPWorker] route1 - sent message to messages channel

The CamelCippaLippa header is deleted after passing from the knative endpoint.

Should be good to have a way to configure through properties, the Stream Caching configuration of the CamelContext.

Should be possible to do it via a ContextCustomizer.

See apache/camel-k#589 (comment)

Customizers are activated by the property

camel.k.customizer

And then configured with properties using the following patter:

customizer.${id}.${property}

Wondering if we should drop camel.k.customizer and use customizer.${id}.enabled to activate/deactivate customizers.

@valdar what do you think ?

we should follow Apache Camel conventions

It should always use POST.

BOM should contain only camel k runtime artifacts

https://builds.apache.org/view/C/view/Apache%20Camel/job/camel-k-merge/39/console

camel-quarkus master is now based on camel-main so we can leverage build time augmentation to bind listeners to main, see:

• https://github.com/apache/camel-quarkus/blob/master/integration-tests/core-main/deployment/src/main/java/org/apache/camel/quarkus/core/runtime/support/deployment/SupportBuildStep.java
• https://github.com/apache/camel-k-runtime/blob/master/camel-k-quarkus/camel-k-runtime-quarkus/runtime/src/main/java/org/apache/camel/k/quarkus/ApplicationRuntime.java

Copied from apache/camel-k#873

With Camel K Client 1.0.0-M1-SNAPSHOT, examples/routes.js doesn't work as follows:

$ kamel run --dev examples/routes.js
[...]
[1] 2019-07-25 02:36:45.686 WARN  [Camel (camel-k) thread #2 - timer://js] TimerConsumer - Error processing exchange. Exchange[ID-routes-5ccdc6b89-jl2c9-1564022203707-0-5]. Caused by: [java.lang.ClassCastException - java.lang.Object cannot be cast to com.oracle.truffle.polyglot.PolyglotLanguageContext]
[1] java.lang.ClassCastException: java.lang.Object cannot be cast to com.oracle.truffle.polyglot.PolyglotLanguageContext
[1] 	at com.oracle.truffle.polyglot.PolyglotLanguage$ContextProfile.profile(PolyglotLanguage.java:383) ~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] 	at com.oracle.truffle.polyglot.HostToGuestRootNode.profileContext(HostToGuestRootNode.java:113) ~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] 	at com.oracle.truffle.polyglot.HostToGuestRootNode.execute(HostToGuestRootNode.java:72) ~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] 	at com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:102) ~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] 	at com.oracle.truffle.polyglot.FunctionProxyHandler.invoke(HostInteropReflect.java:454) ~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] 	at com.sun.proxy.$Proxy28.process(Unknown Source) ~[?:?]
[1] 	at org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:63) ~[org.apache.camel.camel-support-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryState.run(RedeliveryErrorHandler.java:480) ~[org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:185) [org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:59) [org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.processor.Pipeline.process(Pipeline.java:87) [org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:222) [org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:193) [org.apache.camel.camel-timer-3.0.0-M4.jar:3.0.0-M4]
[1] 	at org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:75) [org.apache.camel.camel-timer-3.0.0-M4.jar:3.0.0-M4]
[1] 	at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_191]
[1] 	at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_191]
[1] Caused by: com.oracle.truffle.api.TruffleStackTrace$LazyStackTrace

The error comes from this part. Removing .process(proc) makes the route work.

function proc(e) {
    e.getIn().setHeader('RandomValue', Math.floor((Math.random() * 100) + 1))
}
[...]
    .process(proc)

See also: apache/camel-k#589

This line

In case of the header ce-knativehistory, values may be like: channel1.ns.channels.cluster.local; channel2.ns.channels.cluster.local. They are interpreted by netty as being present multiple times (which is correct) and only one of them is returned by that call (which is correct), but a random one (which is wrong).
We should find a way to get always the last value of the header, which is the last channel that received the message.

I've tried also to get the full list of values using getAll but the order of elements in the list is still randomized.

I've found there's a CombinedHttpHeader class in netty that may solve the issue by appending values to the same header instead of adding multiple entries, but I'm not able to plug it in Camel Netty.

Any idea @lburgazzoli ?

There are some bugfixes and improvements in the Knative area that deserve a new release:

• Fix knative service call (#20)
• Use cloudevents 0.2 (#25)
• Support for health checks (#22, #24)
• Fix catalog (#26)

And allow to customize it using URI parameters other than headers.

see apache/camel-k#506

It looks like the groovy component property setting DSL doesn't throw any exception from the runtime when the property name is wrong.
But when setting the value with method in component with wrong name, the thrown exception is not related to component property setting issue.
So my suggestion is adding error log for it, to help the user to find out the real reason.

mvn clean exec:java fails. The camel-main dependency is missing together with some other camel component dependencies.

We now ave the camel-runtime-jvm that provides route loaders for js, xml and java: in order to have a better support for quarkus (#57) we should further modularize the loaders

We need to release version 0.3.0

• support for camel 3.x

It would be a nice to experiment it. Especially if IDE auto-completion can work with it.

We should start a new minor release in order to have the following fixes:

• add catalog information to runtime artifacts
• fix stream handler
• fix netty http binding for knative
• support stream caching configuration
• honour cutomizer list property/env
• add a default type to cloudevents
• deprecation of spring-boot runtime apache/camel-k#534

In particular, without the fixes to the knative component, Knative CamelSources are not usable.

We need to start testing against camel 3.x as soon as 3.0 M1 get released

We should evaluate switching to the CE library in future releases (> M3).

There are some specific things that it handles better, like content type and support for claim check that we may leverage (https://cloudevents.io/#v03)

Currently Camel K 1.0.0-M2 has a pre-baked list of allowed endpoints that can be used as start or end of a route.

E.g.

from('knative:channel/xx`)

The Knative trait looks for:

• eventing.knative.dev/v1alpha1 -> Channel
• messaging.knative.dev/v1alpha1 -> Channel
• messaging.knative.dev/v1alpha1 -> InMemoryChannel
• messaging.knative.dev/v1alpha1 -> KafkaChannel
• ...

A similar thing happen for the knative/endpoint.

It would be better if a user can explicitly set the target, like:

from('knative:channel/xx?kind=InMemoryChannel')

or even:

from('knative:channel/xx?kind=InMemoryChannel&apiVersion=messaging.knative.dev/v1')

Same also for endpoint. In the case of channel, the operator creates also a subscription.

The resolution of the apiVersion and kind will happen at operator level, but those properties need to be accepted by the runtime.

Wdyt @lburgazzoli ?

Better to name it camel-k-runtime-main