davsclaus opened a new pull request, #28436: URL: https://github.com/apache/camel/pull/28436
JIRA: https://issues.apache.org/jira/browse/CAMEL-25928 **Stacked on #28435** (`javaTypeOption`, which is stacked on #28424): this PR targets its branch. ## What #28435 added `javaTypeOption` to the body types: the option whose value is the class of the body, such as `resultType` of a language. This PR applies it to the data formats and components with such an option. I checked each one against its unmarshal, producer or consumer code, and only the options that really name the class of the body declare it. **Tooling: `javaTypeOption` inside `byOption`.** Some options name the class of the body only for one value of another option, for example the `outputClass` of sql with `outputType=SelectOne`. Otherwise it gives a List of that class, or an iterator. So `@BodyType.When` gets `javaTypeOption` as well, and the following are updated: - `BodyTypeModel.OptionBodyTypeModel` and `JsonMapper`; - the build check: an option of the model, on a body after a step, and not the When's own option; - `camel catalog doc` / MCP: "outputType=SelectOne: map, value or null, or an object of the class outputClass names when it is set"; - `camel.js` (the Message Body section of the doc pages); - `camel-catalog.adoc`. **YAML validator.** Until now, `unmarshalType` was in `dependsOn`, which made the body not known when it was set. With `javaTypeOption`, `CatalogBodyTypes.answer()` now follows the rule of #28435: - an option in `dependsOn` that is set decides first, through `byOption` or as not known; - otherwise the option that names the class gives an object of that class, or null. `Object` says nothing; - otherwise the bodies `byOption` gives for the other options apply, including a `byOption` with its own `javaTypeOption`. Without this change, `gson`, `cbor` or `json` with `unmarshalType: com.acme.Order` were reported as "parsed data (a Map or a List)" (three `TextBodyFlowTest` cases). ### Data formats | Data format | Option | How it is declared | | --- | --- | --- | | fastjson, snakeYaml | `unmarshalType` | `javaTypeOption` (was `dependsOn`) | | gson, jsonb | `unmarshalType` | `javaTypeOption`; `allowUnmarshallType` stays in `dependsOn`, as the header can then name another class | | jackson, avroJackson, protobufJackson, jacksonXml, cbor, ocsf | `unmarshalType` | `javaTypeOption`; `collectionType`, `useList`, `allowUnmarshallType` (and `allowJmsType`) stay in `dependsOn`, as they make the body a collection of the class or let a header name another class. `useList` moved into `dependsOn` so that it decides before `unmarshalType` | | avro | `instanceClassName` | `javaTypeOption` | | protobuf, thrift | `instanceClass` | `javaTypeOption`; thrift also for `contentTypeFormat` binary and json | | jaxb | `partClass` | `javaTypeOption`, while `ignoreJAXBElement` is true (false can give a JAXBElement) | | jsonApi | `mainFormatType` | `javaTypeOption` | ### Components | Component | Option | How it is declared | | --- | --- | --- | | mapstruct | `className` | `javaTypeOption` on producerOut | | language | `resultType` | `javaTypeOption`; `transform` and `binary` in `dependsOn`, as they leave the body unchanged or give the resource as a stream | | jpa | `entityType` | consumerOut (without a query), and producerOut with `findEntity=true` | | sql, jdbc, spring-jdbc | `outputClass` | for `outputType=SelectOne` (one object or null). With SelectList the List holds objects of the class, with StreamList an iterator. The sql consumer has it for each row (with `useIterator` true), and `useIterator`/`outputType` decide first | | spring-ai-chat | `entityClass`; `outputClass` | `entityClass` as `javaTypeOption` (it wins over `outputFormat` at runtime too); `outputClass` for `outputFormat=BEAN` | ### Jackson 3 The camel-jackson3 data formats have no body types, and `PrepareCatalogMojo` keeps them out of the catalog because they share their names with the Jackson 2 ones. Jackson 2 is to be dropped (with the Quarkus 4 upgrade), and then the catalog will read these classes. So they get the same `@BodyTypes` as their Jackson 2 twins. Their generated JSON has the same body types, and the build checks the annotations now. ## Options that do not fit These were checked against the code, and are left as they are: - fory `unmarshalType`: only registers the class. - bindy `classType`: the class, or a List of it. - asn1: an iterator of the class. - parquetAvro: a List or an iterator of the class. - elasticsearch and opensearch `documentClass`: never the body. - openai, llm and langchain4j-agent `outputClass`: the body is JSON text. - rest `outType`: bound only with a binding mode, a JSON or XML response and a success code. - jpa producer `resultClass`: a List. - mongodb `outputType`: an enum. - salesforce `sObjectClass`: depends on the operation, and a header can change it. It could use `byOption` per operation later. ## Tests - **camel-package-maven-plugin:** `BodyTypesHelperJavaTypeOptionTest.javaTypeOptionForAnOptionValue`. - **camel-tooling-model:** the JSON round trip of a `byOption` with `javaTypeOption`. - **camel-jbang-core:** `CatalogDocsTest.anOptionValueCanNameTheClassOfTheBody` (sql). - **camel-yaml-dsl-validator:** `TextBodyFlowTest`. Its gson, cbor and json routes with an `unmarshalType` naming a class say nothing, as before. - **Changed modules:** the tests of all 26 changed data format and component modules pass. - **Local full check:** tooling, the changed modules, regeneration drift, the catalog tests, the YAML DSL and DSL regeneration, and the validator and camel-jbang-core tests. _Claude Code on behalf of davsclaus_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0128ThHB3iQdrvSRLVBGRrdP -- 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]
