davsclaus opened a new pull request, #27367: URL: https://github.com/apache/camel/pull/27367
https://issues.apache.org/jira/browse/CAMEL-24844 ## What A new validator pass, `TextBodyFlow`, in camel-yaml-dsl-validator. It runs next to `BodyTypeFlow` and follows each route step by step. Where the body is certainly still text, it reports a Groovy or simple expression that reads fields of parsed data, and names the step that parses it. Sources of text it knows: - the `file:` consumer (a `GenericFile`) - `setBody` / `transform` with `constant` (including `resource:file:...`) or a simple template - `marshal` - `convertBodyTo` String or `byte[]` - `to: direct:x` when route x ends with one of the above Reads it reports: Groovy `body.find { ... }`, `body.x`, `body['x']`, `body.get(...)`; simple `${body.x}` and `${body[x]}`. Text operations stay allowed: jsonpath, `body.length()`, a regex `find(...)`, `${body[0]}`, and the `GenericFile` properties such as `${body.fileName}`. Anything unknown keeps it silent: other consumers, a bean or processor, an unknown endpoint, a body set from `${header.x}`, or a choice that may set the body. The data format it names comes from the file name or resource extension (through `MimeTypeHelper`), the marshal's data format, or the first character of the text. When none of them tells, it lists the choices. ``` Line 27: route lookup: groovy reads fields of the body (body.find { ... }), but the body here is still text, not parsed data - marshal: json writes data as text (marshal turns data into text, unmarshal turns text into data): to read its fields, unmarshal: json is the step, not marshal Line 42: route getStock: groovy reads fields of the body (body.find { ... }), but the body here is still text, not parsed data - to: direct:lookup returns it as text (setBody with constant: resource:file:stock.json loads the file as text): add unmarshal: json before this step to read its fields ``` ## Measured before opening | corpus | YAML documents | reports | |---|---|---| | routes a local model wrote in the benchmark | 5,962 | 13, each on a step that failed at runtime | | this repository: `.yaml` files, YAML blocks in `.adoc` docs, YAML text blocks in Java and Groovy tests | 4,602 | 5: the 4 positive cases of the new test, and a test fixture with a model-written route that is wrong in the same way | | camel-jbang-examples, camel-examples, camel-kamelets, camel-kamelets-examples, camel-kit, camel-k, Spring Boot and Quarkus examples | 9,111 | 1: an old copy of the to-eip page (below) | No false positives in any of them. ## Doc fix The to-eip page read `${body.templateName}` from a `file:` consumer in its `toD` and `recipientList` examples. That fails at runtime, because the body is the file. The examples now read `${header.templateName}`; the catalog copy and `eip-samples.json` are updated to match. ## Scope The check covers the shapes that failed in the benchmark. Kafka, HTTP consumers, JMS and kamelet sources stay silent, because their body type depends on options. Covering them is the catalog body-type metadata proposed on CAMEL-24844. Tests: `TextBodyFlowTest` (9); the validator module suite passes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01STT6whBgK1AqsSsUKrnE8m -- 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]
