davsclaus opened a new pull request, #25841:
URL: https://github.com/apache/camel/pull/25841
## Summary
`camel validate yaml` (classic/default mode, no `--canonical`) silently
accepts an `expression:` block containing an unknown property and two
mutually-exclusive language choices at once, reporting `Validation success`
when it should fail. Reproduced with the reporter's actual attachment content
(a `choice`/`when` with `expression: { groovy: {...}, simple: {}, hello: world2
}`).
## Root cause
`GenerateYamlSchemaMojo`'s `postProcessInheritance`/`postProcessComposition`
strip `additionalProperties: false` from any definition reused via the
`__extends` "inline shorthand" mechanism — e.g. `ExpressionDefinition`, which
is inlined directly onto `filter`/`resequence`/`onException`/... so that
`filter: { simple: "..." }` works without an explicit `expression:` wrapper.
That relaxation is required for the ["extending closed
schemas"](https://json-schema.org/understanding-json-schema/reference/object.html#extending-closed-schemas)
pattern already referenced in the code's own comment — a `$ref`'d schema
merged directly onto a closed host must itself be open, or the host's own
sibling properties (`id`, `steps`, ...) would be rejected.
The bug: this removal mutated the single, shared `ExpressionDefinition`
definition in place, so the *same* type also lost its closedness when
referenced independently via its own named property (the explicit `expression:
{ groovy: {...} }` form used by ~15 EIPs). Once open, `oneOf` only needs one
alternative (`groovy`) to structurally match; unrelated extra keys (`hello`) or
a second, incomplete alternative (`simple: {}`) are invisible to the validator
since nothing restricts additional properties anymore.
Confirmed by instrumenting the raw `com.networknt.schema` validator directly
(bypassing `YamlValidator`'s own noise-filtering) — the underlying schema
itself accepted the document with zero errors before this fix.
## Fix
Clone the definition instead of mutating it in place in
`postProcessInheritance`: only the clone (named `<Type>$Inline`) loses
`additionalProperties`, and only the bare `$ref` `oneOf`/`anyOf` composition
branches used for inlining get repointed to it. The original definition —
referenced by every explicit named property (`expression: {...}`) — keeps its
`additionalProperties: false`.
This is fully generic: it applies to every type in `inheritedDefinitions`,
not just `ExpressionDefinition` (the generated schema shows the same
clone-and-repoint treatment applied to `OutputAwareFromDefinition` too).
Canonical mode (`--canonical`) was already unaffected by this bug, since it
disables the `__extends` inline mechanism entirely and always requires the
explicit wrapper form.
## Test plan
- [x] Reproduced the reported bug end-to-end with the local `camel` CLI
(`camel validate yaml`) using the reporter's actual attachment content, before
and after the fix
- [x] Confirmed inline shorthand forms (`filter: { simple: "..." }`,
`filter: { groovy: {...} }`) still validate correctly after the fix
- [x] Added
`YamlValidatorTest#testUnknownPropertyInExpressionBlockFailsValidation` using
the reporter's file (`CAMEL-24479.yaml`)
- [x] Added `YamlValidatorTest#testInlineExpressionObjectFormStillValidates`
guarding the inline-merge mechanism against regression
- [x] `mvn test` in `camel-yaml-dsl-validator`, `camel-yaml-dsl`,
`camel-yaml-dsl-maven-plugin`, `camel-yaml-dsl-deserializers`
- [x] Full root `mvn clean install -DskipTests` (mandatory sanity build) —
no unexpected regen drift
---
_Claude Code on behalf of @davsclaus_
Co-Authored-By: Claude Sonnet 5 <[email protected]>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
