oscerd opened a new pull request, #28964:
URL: https://github.com/apache/camel/pull/28964

   Fixes [CAMEL-26265](https://issues.apache.org/jira/browse/CAMEL-26265), 
found while adding the catalog body types (CAMEL-24961).
   
   ## 1. Only a String body counts as JSON
   
   **Was:** `createInstance` read the request from a 
`CreateInstanceRequestBody` or a `String` body only. JSON as a byte[], a stream 
or a file (the body of an HTTP or file consumer) was ignored without a warning, 
and the instance was created from the endpoint options. A `String` that was not 
valid JSON was ignored with a WARN log, with the same result. `updateInstance` 
failed on the same bodies with "Exchange body must include an 
UpdateInstanceRequestBody or a valid JSON String representation of it".
   
   **Now:** both operations convert any other body to text with the type 
converter (`getMandatoryBody(String.class)`), so JSON as a String, byte[], 
InputStream, File or GenericFile is read, in the charset of the exchange. A 
body that is given is the request and is never ignored: a body that is not a 
valid JSON of the request fails with an `IllegalArgumentException`. Its message 
names the expected type and where the JSON is wrong (line and column, or the 
unknown field, such as `engineVersion` for `engine_version`). It does not 
include the message of Jackson, which can quote a value of the body, such as 
`password` or `kafka_manager_password`. `createInstance` creates the instance 
from the endpoint options and exchange properties only when there is no body, 
or an empty one (such as an HTTP request without content). `updateInstance` 
without a body fails as before. The catalog body types (`producerIn`) are 
updated.
   
   ## Tests
   
   - New `InstanceRequestBodyTest` (20 tests) with a Mockito `DmsClient` set on 
the endpoint (`dmsClient=#dmsClient`). The createInstance endpoint also has all 
the options of a Kafka instance, so a body that is ignored shows up as the 
instance `options-instance`. It covers JSON as a String, byte[] (with non-ASCII 
text), InputStream, File and GenericFile for both operations, the POJO, no body 
and an empty body, and the failures: a text that is not JSON, bytes that are 
not JSON (0xff 0xfe), a Map, an unknown field, and a message that does not 
quote the password of the body.
   - `CreateInstanceKafka1Test`, `CreateInstanceKafka2Test`, 
`CreateInstanceRmq1Test`, `CreateInstanceRmq2Test` and 
`CreateInstanceMissingStorageSpaceTest` sent the text `sample_body` to create 
the instance from the options. They now send no body, as the functional tests 
do.
   - With the `src/main` changes reverted, 13 of the 20 new tests fail on the 
bug: JSON as bytes, a stream, a file or a GenericFile creates 
`options-instance`, the bodies that are not JSON create it too instead of 
failing, updateInstance fails on JSON as bytes, a stream or a file, and a text 
that is not JSON fails with the `JsonParseException` of Jackson. The 7 that 
pass are the String JSON and the POJO of both operations, no body and an empty 
body (both use the options), and updateInstance without a body or with bytes 
that are not JSON, which failed before too.
   - Module: 46 tests, 0 failures, 11 skipped (the functional tests, which need 
a Huawei Cloud account).
   
   ## Docs and generated files
   
   Component doc: createInstance and updateInstance read the JSON from text, 
bytes, a stream or a file, createInstance uses the options only without a body, 
and another body fails. The regenerated `hwcloud-dms.json` (body types) is 
copied into the catalog with the doc. Upgrade guide entry for 4.24: 
createInstance fails on a body that is not the request, where it created the 
instance from the options, and updateInstance fails with an 
`IllegalArgumentException` instead of the exception of Jackson.
   
   ## Not changed
   
   - **Open question:** createInstance now fails on any body that is not the 
request. A gentler alternative keeps the old fallback (a WARN log and the 
instance from the options) for a body that is not JSON at all, such as a text 
left by an earlier step, and fails only for a body that looks like JSON (starts 
with `{`) and cannot be read. I did not take it, as it guesses from the first 
character and keeps a body that is silently not used. Should routes that carry 
an unrelated body keep working without clearing it?
   - A `Map` body (such as JSON unmarshalled by an earlier step) is not 
converted to the request with Jackson: it fails like any other body that is not 
the JSON. Marshal it first.
   
   Main only, as the other fixes of the CAMEL-24961 follow-ups.
   
   _Claude Code on behalf of Andrea Cosentino (oscerd)_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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]

Reply via email to