[
https://issues.apache.org/jira/browse/CAMEL-24704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24704 started by Adriano Machado.
-----------------------------------------------
> 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
> Assignee: Adriano Machado
> Priority: Major
>
> 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)
