Claus Ibsen created CAMEL-25194:
-----------------------------------
Summary: The tools cannot author a custom Kamelet: the validator
checks a .kamelet.yaml against the route schema
Key: CAMEL-25194
URL: https://issues.apache.org/jira/browse/CAMEL-25194
Project: Camel
Issue Type: Bug
Components: camel-jbang
Reporter: Claus Ibsen
Writing a custom Kamelet cannot be done through the tools. The validator treats
every YAML file as a list of route entries, so a {{.kamelet.yaml}}, which is
legitimately a YAML object, is rejected -- and because {{camel_write_file}} and
{{camel_edit_file}} validate before they write, the file cannot be written at
all.
h3. Reproducing it
This Kamelet runs correctly. {{camel run demo.camel.yaml
content-filter-action.kamelet.yaml}} logs {{analytics: {"country" : "DK",
"orders" : 3}}}, the two PII fields stripped:
{code:yaml}
apiVersion: camel.apache.org/v1
kind: Kamelet
metadata:
name: content-filter-action
labels:
camel.apache.org/kamelet.type: action
spec:
definition:
title: Content Filter
properties:
allowlist:
title: Allowlist
type: string
template:
from:
uri: kamelet:source
steps:
- setBody:
expression:
jq:
expression: 'with_entries(select(.key as $k | "{{allowlist}}" |
split(",") | index($k)))'
{code}
The same file, through each surface:
{noformat}
$ camel validate yaml content-filter-action.kamelet.yaml
Validation error detected (errors:1)
File: content-filter-action.kamelet.yaml
: object found, array expected (a Camel YAML file is a list of entries,
each
starting with "- ": - route:, - from:, - beans:, - rest:, -
onException:)
camel_validate_source -> the same error
camel_write_file -> {"status":"invalid", ... "The file was not written:
the
content has validation errors."}
{noformat}
So the loader and the validator disagree about what a {{.kamelet.yaml}} is:
{{KameletRoutesBuilderLoader}} loads it, {{YamlValidator}} in
camel-yaml-dsl-validator checks it against {{camelYamlDsl.json}}, the route
schema, and there is no Kamelet schema in the repo.
h3. It also misdirects when the error is real
Before the version above, the {{jq}} step was written as a step of its own,
which is not a thing. The loader failed at line 20 -- correctly -- but
{{YamlLoadFailureReport}} printed the "object found, array expected" hint
again, pointing at the envelope instead of at line 20. Two wrong diagnoses in a
row, both away from the fault.
h3. What else is missing for authoring a Kamelet
* {{camel_catalog_sample}} with {{name=kamelet}} returns the *usage* shape
({{to: uri: kamelet:my-aggregate}}), not the shape of a {{.kamelet.yaml}}.
There is no sample of the envelope, the {{kamelet.type}} label,
{{spec.definition}} as a JSON-schema fragment, {{from: uri: kamelet:source}},
or how a {{{{property}}}} of the definition is referenced in the template.
* {{camel_catalog_docs}} lists no kamelet page, so there is nothing to read
either.
* {{camel_catalog_kamelets}} and {{camel_catalog_kamelet_doc}} are consumption
only: list the catalog, describe one that exists. Nothing covers writing one.
h3. Suggested direction
# Validate a Kamelet as a Kamelet. Detect it the way the loader does ({{kind:
Kamelet}}, or the {{.kamelet.yaml}} suffix) and check {{spec.template}} against
the route schema while the envelope is checked on its own. The split already
exists in {{KameletRoutesBuilderLoader}}; the validator can follow it. Until
the envelope is schema-checked, recognising the file and validating only the
template would already unblock authoring.
# Fix the hint. A Kamelet author must not be told to start the file with {{-
}}, in {{camel validate yaml}}, in {{camel_validate_source}} or in
{{YamlLoadFailureReport}}.
# Give the authoring shape somewhere to be found: a {{.kamelet.yaml}} sample
from {{camel_catalog_sample}}, and a page reachable from {{camel_catalog_docs}}.
h3. Why it matters now
Custom Kamelets are how a policy-level transformation gets written once and
reused, and the workflow has just been documented for the visual editor
(https://kaoto.io/blog/2026/custom-kamelets/). The same task over the CLI and
the camel-jbang-mcp server should work as well: an agent that follows the
supported path cannot write the file at all today, and would have to go around
the tools to do it.
Found while checking how a model would do that task with the CLI and the MCP
server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)