Claus Ibsen created CAMEL-24704:
-----------------------------------
Summary: camel-yaml-dsl - accept beans (and other name-keyed
lists) written as a map keyed by name
Key: CAMEL-24704
URL: https://issues.apache.org/jira/browse/CAMEL-24704
Project: Camel
Issue Type: Improvement
Components: camel-yaml-dsl
Reporter: Claus Ibsen
In the YAML DSL beans are a list of items with a name property:
{code}
- beans:
- name: myProcessor
type: "#class:com.example.MyProcessor"
{code}
Every other configuration format keys a bean by its name, and that is what both
people and AI models write first (seen in 3 of the 6 benchmark runs on
2026-09-12, every time as one of these two shapes):
{code}
- beans:
myProcessor:
type: "#class:com.example.MyProcessor"
{code}
{code}
- beans:
- myProcessor:
type: "#class:com.example.MyProcessor"
{code}
Both are rejected ("object found, array expected", "required property 'name'
not found"). Since a bean name is unique in the file, the map form is
unambiguous, and YAML maps keep their order, so nothing is lost. Proposal:
accept the map form as an alternative, keep the list as the canonical form (the
normalizer and the canonical validator keep producing and requiring the list),
and document only one of them as primary.
Where: BeansDeserializer (hand written, camel-yaml-dsl-deserializers) reads a
MappingNode as name -> bean; GenerateYamlSchemaMojo emits beans as oneOf [the
current array, an object with additionalProperties: the bean definition]; the
YAML DSL validator and the TUI/MCP validation follow the schema; Kaoto and
other consumers of the schema need to read both forms.
Other lists in the schema whose items are identified by a required name, found
by walking camelYamlDsl.json, where the same map form would be as natural:
|| property || item type || used by || map form ||
| beans | BeanFactoryDefinition | root, routeTemplate, templatedRoute | beans:
{myBean: {type: ...}} |
| parameters | RouteTemplateParameterDefinition /
TemplatedRouteParameterDefinition | routeTemplate, templatedRoute | parameters:
{name: {defaultValue: ...}} or name: default |
| headers | SetHeaderDefinition | setHeaders | headers: {foo: {constant: x}} |
| variables | SetVariableDefinition | setVariables | variables: {foo: {simple:
...}} |
| param | ParamDefinition | rest get/post/put/delete/patch/head | param: {id:
{type: path, ...}} |
| header | ResponseHeaderDefinition | rest responseMessage | header: {name:
{...}} |
| univocityHeader | UniVocityHeader | univocity data formats | (rare) |
Lists whose items only have an optional id (rest, get/post, when, doCatch) have
no natural key and should stay lists.
Suggested order: beans first (the case that fails in practice), then
setHeaders/setVariables and the template parameters, which a model also tends
to write as maps. Each needs the deserializer, the schema, a validator test and
a doc line. Found while benchmarking a local model against the YAML DSL; the
validator on CAMEL-24698 meanwhile tells the user how to rewrite the map form
as the list.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
