[
https://issues.apache.org/jira/browse/CAMEL-24851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24851.
---------------------------------
Resolution: Fixed
> camel-jbang - when a YAML route fails to load, camel run prints the schema
> validator's report (what to write), not only the loader's message
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24851
> URL: https://issues.apache.org/jira/browse/CAMEL-24851
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.23.0
>
>
> When a YAML route fails to load, {{camel run}} prints the loader's message,
> for example
> {noformat}
> Error starting Camel: Error constructing YAML node id: pollEnrich:
> unsupported field: uri
> {noformat}
> which knows the field is wrong but not what to write. The schema validator
> (camel-yaml-dsl-validator, already a dependency of camel-jbang-core) has the
> message that says what to write, with the hints that keep being added to it
> (CAMEL-24698, CAMEL-24836, CAMEL-24850...), but {{camel run}} never calls it:
> only {{camel validate yaml}} and the MCP validate tool do. The round-2
> benchmark shows the effect: of 67 attempts that failed at startup, 54 had a
> validator message that said what to write, and it was never shown because the
> file was run without validating first. People prototyping with the CLI do the
> same: write, run, read the error.
> Proposal, in the CLI, not the runtime:
> * on a failed start whose cause is a YAML load error
> ({{YamlDeserializationException}} / "Error constructing YAML node" / "Error
> pre-parsing resource"), {{camel run}} runs the schema validator on the file
> the loader named and prints its report; the report first (it may list several
> problems in the file, which is the better outcome), the exception after
> * the same on a failed reload in {{--dev}} mode, so the edit-save loop gets
> the better message on each save
> * the MCP run tool and the camel-jbang views ({{camel-jbang-mcp}} server)
> carry the report in their result, so an agent sees it in the tool output, not
> only in the log
> The runtime stays as is: the validator depends on the catalog and is a
> camel-jbang thing. Spring Boot and Quarkus users keep the loader's message,
> which gets its own hints where they matter (the unmarshal/jackson one exists).
> Every hint added to the validator then reaches everyone who runs, whether
> they validated first or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
