[
https://issues.apache.org/jira/browse/CAMEL-22169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond updated CAMEL-22169:
----------------------------
Description:
Currently, there are a couple of ways to load resources, such as scripts,
templates. Think of XSLT, Jsonata, Velocity, Mustache etc.
For this, the generic "Resource" loader is used. By default this is using the
classpath, but it can also load from file, url or bean.
When using a low-code platform, GUI or other used defined thing, these
resources are loaded on start dynamically in runtime. Because of this, the
default "classpath" is unusable. File is also not a good option as user don't
have access to the filesystem and you need the volumes of containers to be
persistent.
The best option (and what we use now) is to host the resource, and then access
the url through https.
However this means:
- You need an additional hosting by either a third-party (let's say [Apicurio
registry|https://www.apicur.io/registry/]
or some self host file). Yes, it can also be done in the Camel registry, but
that's not persistent.
The result is that when you start a route, the starting of the route becomes
dependent on this external api. So that means you not only require an extra
tool/api/certificate, but you also need to be careful when you migrate the
Camel configuration. For example we migrated the Camel routes from a database
to another machine, but we forget about such files. Then the routes didn't
start anymore.
It's also harder to test, because mostly these files are secured and you cannot
reach them. Because they are separate from the route, the often are not
available when a developers wants to debug the route (so he needs to get them
and put it on the classpath or filesystem).
So when the API is not available, or the resource is not available, the route
will not start properly. Besides, loading external resources like scripts and
template can bring additional security configuration and issues.
I see similar limitations in Kamelets. For example mustache-action:
{code:java}
spec:
definition:
title: "Mustache Template Action"
description: |-
Apply a Mustache Template.
required:
- template
type: object
properties:
template:
title: Template
description: The inline template.
type: string
example: "file:////template.mustache"
pattern: "^(http|https|file|classpath)://.*"
dependencies:
- "camel:mustache"
- "camel:kamelet"
template:
from:
uri: "kamelet:source"
steps:
- to:
uri: "mustache:"
parameters:
resourceUri: "{{template}}" {code}
Alternatively, you could write a custom bean:
{code:java}
public class TemplateBean {
public String getTemplate() {
return "Dear {{headers.lastName}}, {{headers.firstName}}\n\n" +
"Thanks for the order of {{headers.item}}.\n\n" +
"Regards Camel Riders Bookstore\n{{body}}";
}
} {code}
But I think Kamelets and low-code platforms like to avoid it.
In some cases, there is a query parameter like this:
*allowTemplateFromHeader*
However, this is
* Not generic implemented (as for example this issue show:
https://issues.apache.org/jira/browse/CAMEL-22112)
* Not supersafe (as now it can be overwritten by a user / external producer
and inject code)
* Not performant, as this means loading it on every exchange.
I would like to have it something like this:
{code:java}
<route id="myRoute">
<resource name="mytemplate">Dear {{headers.lastName}},
{{headers.firstName}}
Thanks for the order of {{headers.item}}.
Regards Camel Riders Bookstore
{{body}}
</resource>
<from uri="direct:start"/>
<to uri="mustache:ref:mytemplate"/>
</route>
{code}
Thus this is a bit nice to have, but as others may find it practical too, then
it would be nice to load resources as string directly from the route on startup.
was:
Currently, there are a couple of ways to load resources, such as scripts,
templates. Think of XSLT, Jsonata, Velocity, Mustache etc.
For this, the generic "Resource" loader is used. By default this is using the
classpath, but it can also load from file, url or bean.
When using a low-code platform, GUI or other used defined thing, these
resources are loaded on start dynamically in runtime. Because of this, the
default "classpath" is unusable. File is also not a good option as user don't
have access to the filesystem and you need the volumes of containers to be
persistent.
The best option (and what we use now) is to host the resource, and then access
the url through https.
However this means:
- You need an additional hosting by either a third-party (let's say [Apicurio
registry|https://www.apicur.io/registry/]
or some self host file). Yes, it can also be done in the Camel registry, but
that's not persistent.
The result is that when you start a route, the starting of the route becomes
dependent on this external api. So that means you not only need an extra
tool/api/certificate, but you also need to be careful when you migrate the
Camel configuration. For example we migrated the Camel routes from a database
to another machine, but we forget about such files. Then the routes didn't
start anymore.
So when the API is not available, or the resource is not available, the route
will not start properly. Besides, loading external resources like scripts and
template can bring additional security configuration and issues.
I see similar limitations in Kamelets. For example mustache-action:
{code:java}
spec:
definition:
title: "Mustache Template Action"
description: |-
Apply a Mustache Template.
required:
- template
type: object
properties:
template:
title: Template
description: The inline template.
type: string
example: "file:////template.mustache"
pattern: "^(http|https|file|classpath)://.*"
dependencies:
- "camel:mustache"
- "camel:kamelet"
template:
from:
uri: "kamelet:source"
steps:
- to:
uri: "mustache:"
parameters:
resourceUri: "{{template}}" {code}
Alternatively, you could write a custom bean:
{code:java}
public class TemplateBean {
public String getTemplate() {
return "Dear {{headers.lastName}}, {{headers.firstName}}\n\n" +
"Thanks for the order of {{headers.item}}.\n\n" +
"Regards Camel Riders Bookstore\n{{body}}";
}
} {code}
But I think Kamelets and low-code platforms like to avoid it.
In some cases, there is a query parameter like this:
*allowTemplateFromHeader*
However, this is
* Not generic implemented (as for example this issue show:
https://issues.apache.org/jira/browse/CAMEL-22112)
* Not supersafe (as now it can be overwritten by a user / external producer
and inject code)
* Not performant, as this means loading it on every exchange.
I would like to have it something like this:
{code:java}
<route id="myRoute">
<resource name="mytemplate">Dear {{headers.lastName}},
{{headers.firstName}}
Thanks for the order of {{headers.item}}.
Regards Camel Riders Bookstore
{{body}}
</resource>
<from uri="direct:start"/>
<to uri="mustache:ref:mytemplate"/>
</route>
{code}
Thus this is a bit nice to have, but as others may find it practical too, then
it would be nice to load resources as string directly from the route on startup.
> Load resources dynamically from strings or exchange
> ---------------------------------------------------
>
> Key: CAMEL-22169
> URL: https://issues.apache.org/jira/browse/CAMEL-22169
> Project: Camel
> Issue Type: Wish
> Components: came-core
> Affects Versions: 4.12.0
> Reporter: Raymond
> Priority: Minor
>
> Currently, there are a couple of ways to load resources, such as scripts,
> templates. Think of XSLT, Jsonata, Velocity, Mustache etc.
> For this, the generic "Resource" loader is used. By default this is using the
> classpath, but it can also load from file, url or bean.
> When using a low-code platform, GUI or other used defined thing, these
> resources are loaded on start dynamically in runtime. Because of this, the
> default "classpath" is unusable. File is also not a good option as user don't
> have access to the filesystem and you need the volumes of containers to be
> persistent.
> The best option (and what we use now) is to host the resource, and then
> access the url through https.
> However this means:
> - You need an additional hosting by either a third-party (let's say
> [Apicurio registry|https://www.apicur.io/registry/]
> or some self host file). Yes, it can also be done in the Camel registry, but
> that's not persistent.
> The result is that when you start a route, the starting of the route becomes
> dependent on this external api. So that means you not only require an extra
> tool/api/certificate, but you also need to be careful when you migrate the
> Camel configuration. For example we migrated the Camel routes from a database
> to another machine, but we forget about such files. Then the routes didn't
> start anymore.
> It's also harder to test, because mostly these files are secured and you
> cannot reach them. Because they are separate from the route, the often are
> not available when a developers wants to debug the route (so he needs to get
> them and put it on the classpath or filesystem).
> So when the API is not available, or the resource is not available, the route
> will not start properly. Besides, loading external resources like scripts and
> template can bring additional security configuration and issues.
> I see similar limitations in Kamelets. For example mustache-action:
> {code:java}
> spec:
> definition:
> title: "Mustache Template Action"
> description: |-
> Apply a Mustache Template.
> required:
> - template
> type: object
> properties:
> template:
> title: Template
> description: The inline template.
> type: string
> example: "file:////template.mustache"
> pattern: "^(http|https|file|classpath)://.*"
> dependencies:
> - "camel:mustache"
> - "camel:kamelet"
> template:
> from:
> uri: "kamelet:source"
> steps:
> - to:
> uri: "mustache:"
> parameters:
> resourceUri: "{{template}}" {code}
> Alternatively, you could write a custom bean:
> {code:java}
> public class TemplateBean {
> public String getTemplate() {
> return "Dear {{headers.lastName}}, {{headers.firstName}}\n\n" +
> "Thanks for the order of {{headers.item}}.\n\n" +
> "Regards Camel Riders Bookstore\n{{body}}";
> }
> } {code}
> But I think Kamelets and low-code platforms like to avoid it.
> In some cases, there is a query parameter like this:
> *allowTemplateFromHeader*
> However, this is
> * Not generic implemented (as for example this issue show:
> https://issues.apache.org/jira/browse/CAMEL-22112)
> * Not supersafe (as now it can be overwritten by a user / external producer
> and inject code)
> * Not performant, as this means loading it on every exchange.
> I would like to have it something like this:
> {code:java}
> <route id="myRoute">
> <resource name="mytemplate">Dear {{headers.lastName}},
> {{headers.firstName}}
> Thanks for the order of {{headers.item}}.
> Regards Camel Riders Bookstore
> {{body}}
> </resource>
> <from uri="direct:start"/>
> <to uri="mustache:ref:mytemplate"/>
> </route>
> {code}
>
> Thus this is a bit nice to have, but as others may find it practical too,
> then it would be nice to load resources as string directly from the route on
> startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
