[
https://issues.apache.org/jira/browse/CAMEL-24697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114597#comment-18114597
]
Claus Ibsen commented on CAMEL-24697:
-------------------------------------
Closing out the anyOf follow-up from the previous comment: checked against the
Kaoto source (2026-09-11 checkout). Kaoto's expression editor locates the
expression group by walking {{schema.anyOf[0]}} then {{oneOf[0]}}
({{expression.service.ts}}), and its model validation only descends into
{{anyOf}} and {{oneOf}}. Joining the resequence groups with {{allOf}} would
therefore remove the expression field from the resequence form in Kaoto until
Kaoto is changed as well.
ResequenceDefinition is the only definition with two oneOf groups, the EIP is
seldom used, and the only thing the {{anyOf}} join hides is a wrong scalar
inside batchConfig/streamConfig, which the validator is about to accept anyway
under CAMEL-24694. Not worth a coordinated cross-project change: leaving the
{{anyOf}} join as is. The changes in PR 26355 are Kaoto-safe (the completed
not-branch matches the shape Kaoto's own setHeader test stub already has, and
the two new {{inheritErrorHandler}} properties simply become form fields).
_Claude Code on behalf of davsclaus_
> camel-yaml-dsl - JSON schema rejects EIP doc examples the runtime accepts:
> inheritErrorHandler, resequence expression oneOf, jaxb contextPath
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24697
> URL: https://issues.apache.org/jira/browse/CAMEL-24697
> Project: Camel
> Issue Type: Bug
> Components: camel-yaml-dsl
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.23.0
>
>
> h3. Background
> Found while working on CAMEL-24693 (validated per-EIP YAML sample set). After
> the doc-side fixes for the EIP examples that were written in the XML child
> shape, three groups of EIP documentation examples still fail {{camel validate
> yaml}} even though the runtime loads and starts them fine (checked with
> {{CamelYamlParser}} from camel-yaml-dsl-validator on 4.23.0-SNAPSHOT). All
> three are the generated YAML DSL JSON schema ({{camelYamlDsl.json}}) being
> stricter than the runtime.
> h3. 1. {{inheritErrorHandler}} is missing on {{circuitBreaker}} and
> {{failoverLoadBalancer}}
> {{GenerateYamlSchemaMojo}} skips {{inheritErrorHandler}} for every definition
> except the one whose {{@YamlType}} nodes contain {{loadBalance}} ("we want to
> skip inheritErrorHandler which is only applicable for the load-balancer").
> But the generated {{ModelDeserializers}} accept the key on both
> {{CircuitBreakerDefinition}} and {{FailoverLoadBalancerDefinition}}, both
> model classes declare it with {{@Metadata}}, and the EIP docs use it:
> {noformat}
> fault-tolerance-3.camel.yaml: /0/route/from/steps/1/circuitBreaker:
> property 'inheritErrorHandler' is not defined in the schema and the schema
> does not allow additional properties
> resilience4j-4.camel.yaml: /0/route/from/steps/1/circuitBreaker:
> property 'inheritErrorHandler' is not defined in the schema and the schema
> does not allow additional properties
> failoverLoadBalancer-2.camel.yaml:
> /0/route/from/steps/0/loadBalance/failoverLoadBalancer: property
> 'inheritErrorHandler' is not defined in the schema and the schema does not
> allow additional properties
> failoverLoadBalancer-3.camel.yaml:
> /0/route/from/steps/0/loadBalance/failoverLoadBalancer: property
> 'inheritErrorHandler' is not defined in the schema and the schema does not
> allow additional properties
> {noformat}
> Note the interaction with CAMEL-24696: both attributes are still converted
> eagerly with {{Boolean.valueOf}} while deserializing, so once they are
> exposed in the schema the placeholder leniency from CAMEL-24694 in
> {{YamlValidator.isRuntimeAcceptedScalar}} would accept {{inheritErrorHandler:
> "{{flag}}"}} while the runtime silently evaluates it to {{false}}. Either
> port the two fields first (CAMEL-24696) or exclude them in
> {{isRuntimeAcceptedScalar}} when adding them to the schema.
> h3. 2. {{resequence}} with the {{expression:}} wrapper matches two oneOf
> branches
> Every expression-carrying EIP gets a {{oneOf}} with three branches: the
> inline language form ({{simple: ...}}), a {{not}} branch that excludes all
> the language keys, and the {{expression:}} wrapper form. For
> {{SplitDefinition}}, {{FilterDefinition}} etc. the {{not}} branch also
> excludes {{expression}}, so the wrapper form matches exactly one branch. For
> {{ResequenceDefinition}} the {{not}} branch does not list {{expression}}, so
> the wrapper form matches both the {{not}} branch and the wrapper branch:
> {noformat}
> resequence-2.camel.yaml: /0/route/from/steps/0/resequence: must be valid to
> one and only one schema, but 2 are valid with indexes '1, 2'
> {noformat}
> 8 of the 11 examples on the resequence page fail this way (resequence-2, -4,
> -5, -6, -7, -9, -10, -11). {{ResequenceDefinition}} is the only definition
> with two {{anyOf}} groups (expression, and batchConfig/streamConfig), which
> is probably why the generator drops {{expression}} from the exclusion list.
> Fix belongs in {{GenerateYamlSchemaMojo}}.
> h3. 3. {{jaxb}} data format requires {{contextPath}} in the schema but not at
> runtime
> {{JaxbDataFormat.contextPath}} in camel-core-model is {{@Metadata(required =
> true)}}, so the schema requires it and {{marshal: jaxb: {}}} / {{unmarshal:
> jaxb: {}}} on the marshal and unmarshal EIP pages fail:
> {noformat}
> marshal-1.camel.yaml: /0/route/from/steps/0/unmarshal: must be valid to one
> and only one schema, but 0 are valid
> /0/route/from/steps/0/unmarshal/jaxb: required
> property 'contextPath' not found
> {noformat}
> The runtime does not require it:
> {{org.apache.camel.converter.jaxb.JaxbDataFormat#createContext}} falls back
> to {{JAXBContext.newInstance()}} when {{contextPath}} is null, and the Java
> DSL {{.jaxb()}} takes no arguments. Either drop {{required = true}} from the
> model metadata (which also fixes the catalog and Kaoto forms) or, if the PMC
> prefers the stricter contract, change the docs to show a context path.
> h3. Done when
> * {{inheritErrorHandler}} validates on {{circuitBreaker}} and
> {{failoverLoadBalancer}} without accepting a placeholder the runtime gets
> wrong;
> * the resequence examples with the {{expression:}} wrapper validate against
> exactly one branch;
> * {{jaxb: {}}} validates, or the docs are changed and the reason recorded
> here;
> * {{camel validate yaml}} passes on the 14 affected EIP doc examples listed
> above (with CAMEL-24694 merged for the remaining scalar-type messages).
> Related: CAMEL-24693 (sample set, and the doc-side fixes for the XML child
> shape), CAMEL-24694 (scalar leniency), CAMEL-24696 (eager Boolean conversion
> of inheritErrorHandler).
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
