[
https://issues.apache.org/jira/browse/CAMEL-24850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24850.
---------------------------------
Fix Version/s: 4.23.0
Resolution: Fixed
> camel-yaml-dsl-validator - say what to write for pollEnrich/enrich with a
> uri, a steps item inside steps, and EIPs directly under step
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24850
> URL: https://issues.apache.org/jira/browse/CAMEL-24850
> Project: Camel
> Issue Type: Improvement
> Components: camel-yaml-dsl
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.23.0
>
>
> The round-2 benchmark (series l2, 155 attempts of a local model on the
> camel-jbang-examples ladder) shows two shapes the schema validator rejects
> with a message that does not say what to write, so the model (and a person)
> needs another round or two to get past it. Both are one row each in
> {{SchemaHints}} (camel-yaml-dsl-validator), in the style of the rows that
> exist.
> *1. pollEnrich / enrich with a uri*
> {code:yaml}
> - pollEnrich:
> uri: file:./order.json
> {code}
> reported as {{/0/route/from/steps/0/pollEnrich: property 'uri' is not defined
> in the schema and the schema does not allow additional properties}}. The
> endpoint of enrich and pollEnrich is an expression; the message should say
> the form: {{pollEnrich: {expression: {constant: {expression:
> "file:./order.json"}}}}} (classic schema also accepts {{pollEnrich:
> {constant: "file:./order.json"}}}). Seen in 3 attempts of 3 examples; all
> three ran the file anyway and failed at startup with "pollEnrich: unsupported
> field: uri".
> *2. steps as a grouping item, and step with EIPs as direct keys*
> The model groups a few EIPs by writing a {{steps}} item inside a steps list:
> {code:yaml}
> steps:
> - steps:
> - setHeader: ...
> - setHeader: ...
> - aggregate: ...
> {code}
> reported as {{property 'steps' is not defined in the schema ... (did you mean
> 'step'?)}}. The did-you-mean points to the Step EIP, the model follows it and
> writes
> {code:yaml}
> - step:
> setHeader: ...
> setHeader: ...
> split: ...
> {code}
> which is reported as {{/1/route/from/steps/2/step: property 'setHeader' is
> not defined in the schema}} once per EIP, without the shape Step has. Two
> rounds lost on one misunderstanding, and the did-you-mean caused the second.
> A third variant puts {{steps:}} on an EIP that has no pipeline ({{to: {uri:
> ..., steps: [...]}}}). Seen in 7 attempts (aggregator, openapi-client,
> openapi-server, http-client).
> Rows to add:
> * an unknown {{steps}} property (an item of a steps list, or on an EIP
> without a pipeline): "steps: is the list of a route or of an EIP that owns a
> pipeline (filter, split, choice, step); an EIP is an item of that list, not a
> group inside it: move the items up, or use step: {id: ..., steps: [...]} for
> a named group", and no did-you-mean for this case
> * an unknown EIP name directly under {{step}}: "step is the Step EIP, a named
> group: its EIPs go in its steps: list (step: {id: ..., steps: [- setHeader:
> ...]})"
> Tests in {{YamlValidatorPropertyHintTest}} or a new class, both schema modes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
