davsclaus commented on PR #28457:
URL: https://github.com/apache/camel/pull/28457#issuecomment-6417098867
@skin27 thanks Raymond, this is very useful, and the order route is a great
test case. We share the aim: no Java types (`GenericFile`, `InputStream`,
`LinkedHashMap`) in the way of a low-code user.
**Data or text in the route.** We keep the `json` mode as JSON data in the
route. The point is that users read a few fields as `body.sku` in Groovy and
`${body.sku}` in simple, without learning jsonpath or jq, and without `new
JsonSlurper().parseText(body)` in every mapping. With text in the route, that
parsing code (or jsonpath/jq) is back in every step that reads a field.
Your model fits the same SPI as a plugin of its own, so it is not either/or:
a `text` mode, where a text payload (JSON, XML, CSV, plain text) is a `String`
and a binary one a `byte[]`, and a `Map`, `List` or DOM `Node` that a step
returns becomes text by the `Content-Type`. It is now in the formats on paper,
and `payloadMode=json,text` is in the open question on more than one mode per
route: JSON payloads become data, XML, CSV and plain text become a `String`.
**One correction of the review:** the `json` mode does not try to turn every
body into a `JsonObject`. It claims JSON payloads only; the XML from your step
5 is left as it is, so steps 6 to 8 (log, xslt, SOAP) run as today. The doc now
walks through your route step by step ("A route with more than one format"). It
also states the gap you point at: an XML or CSV file that arrives at the
consumer is not JSON, so in `json` mode alone it stays a `GenericFile`;
`json,text` closes that.
What the review added to the doc, in 8522f2853028:
- **A stale `Content-Type`.** The header that came with the JSON stays when
a step turns it into XML (the data formats set it, xslt and the languages
don't). After a step that changed the body, a body that does not parse although
the header names JSON is a stale header: the body is left as it is and the
header is removed, so a producer does not send XML as `application/json`.
- **No silent fallback for a sender's broken JSON.** When the sender's
`Content-Type` says JSON and the payload does not parse, the message fails at
the consumer with an error that says so. A body that was only sniffed or
matched by file name is left as it is.
- **The format in tooling.** The tracer, the backlog tracer and the dev
consoles show the format of the body (JSON, or from the `Content-Type`: XML,
CSV, binary) next to its Java type.
- **JsonSlurper.** `parseText(body)` fails in `json` mode, since the body is
already data; the Groovy hint will say to use `body.sku`.
Two things stay out of this proposal: a format-to-format conversion step
(JSON to XML, CSV to JSON) is a topic of its own, and declaring accepted and
produced formats for every EIP and language in the catalog belongs to the
tooling work later.
_Claude Code on behalf of davsclaus_
--
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]
