Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for template endpoint #249

Open
nicolaferraro opened this issue Nov 30, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@nicolaferraro
Copy link
Contributor

commented Nov 30, 2018

I would like to write a route as:

from("timer:tick")
  .to("template:out")

... leaving the last endpoint open.
Then you can provide the actual value of out in the trait configuration, like: kamel run -t template.out=knative:channel/a.

The reason why we don't just use placeholder here is that having the actual value in the trait configuration allows to add the required libraries at build time.

It will support named endpoint, so we can template sources, sink and patterns with this strategy.

E.g.

from("template:source")
  .split().tokenize(" ")
  .to("template:sink")

Then provide the value for "source" and "sink".

This is a simpler requirement than using a "routebox-like" strategy for creating "connectors", but it should be enough flexible to create e.g. a CamelSource in Knative.

Thoughts @lburgazzoli, @chirino, @davsclaus, @valdar, @zregvart, @oscerd, @gnodet ?

@zregvart

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2018

I see template:out and in the example template.out, that's a bit confusing.

I would rather introduce placeholders perhaps via go templates and then have traits triggered on the endpoints used. Would that make (more?) sense?

Something like: from("{{.In}}").to("{{.Out}}")
and kamel run -p In=knative:channel/a -p Out=knative:channel/b

And then the knative endpoint schema triggerers the knative trait.

@nicolaferraro

This comment has been minimized.

Copy link
Contributor Author

commented Nov 30, 2018

Well, I don't think it's a problem the confusion around template.out and the URI counterpart, as templating is needed in order to create higher level resources than Integration: users will not run them directly (after the definition phase), they'll create the higher level resources that then instantiate integrations under the hood.

Also kamel is already reporting errors when somebody uses wrong property names (like -t template:out=xxx).

Having template: as a proper endpoint allows to use standard Camel property binding and standard Camel K traits configuration without any change..

@davsclaus

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2018

Okay so template from Camel point of view is just like any other Camel component. The template component is then capable of referring to an actual concrete endpoint. How this is mapped can be implementation specific in the template component, so it can support looking up via ENV variables, property placeholders, load from resource file etc.

@davsclaus

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2018

@nicolaferraro I think this is a good idea, and since the template component is a component then its not a drastic change in camel-core etc, and it allows us to change its implementation with more ease and if down the road it turns out it was not as a good idea as we thought, then we can easier deprecate/remote the component and make a better new solution.

@nicolaferraro

This comment has been minimized.

Copy link
Contributor Author

commented Dec 18, 2018

I was looking in the Camel catalog and I've found a similar component that we may be able to reuse: https://github.com/apache/camel/blob/master/camel-core/src/main/docs/stub-component.adoc

Wdyt?

@davsclaus

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2018

Oh the stub component will not create an actual endpoint of what endpoint uri is defined. So in your example with knative then stub will not create the knative Camel endpoint, but just stub it out.

The fact that stub uses an internal VM queue under the hood is a bit of purpose, in case you stub out endpoints that was intended to be bridged.

So yeah in this example with sink/source you can say

from timer foo
to template bar

from template bar
to log info

But they have to run in the same Camel JVM to bridge them together.

Don't you want template to create the actual endpoint, eg knative in this example?

@nicolaferraro

This comment has been minimized.

Copy link
Contributor Author

commented Dec 18, 2018

Yeah, I've never used it, but I see it has a different behavior than the one we require here.

@davsclaus

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2018

Yeah its not so often in use, it was actually created when James and I was tired of getting a bunch of sample XML routes / Java Routes from end users or customers and something didn't work, and we needed to bootup their routes. So we needed to stub out their own components, or irrelevant Camel components etc. So stub was faster to add than to replace all of these uris with seda etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.