[jira] [Assigned] (CAMEL-24704) camel-yaml-dsl - accept beans (and other name-keyed lists) written as a map keyed by name

["Adriano Machado (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adriano Machado reassigned CAMEL-24704:
---------------------------------------

    Assignee: 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)