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

   _Claude Code on behalf of davsclaus_
   
   This group adds the catalog body types (CAMEL-24961) for eleven components:
   - google-calendar, google-drive, google-mail and google-sheets, and their 
stream consumers google-calendar-stream, google-mail-stream and 
google-sheets-stream;
   - azure-cosmosdb, azure-functions, azure-key-vault and 
azure-storage-datalake.
   
   Each change is an `@BodyTypes` annotation on the Endpoint, plus the JSON it 
generates and the catalog copy. Two doc pages had their examples corrected.
   
   **What the catalog says now**
   
   | Component | Consumer | Producer input | Producer output |
   |---|---|---|---|
   | google-calendar, -drive, -mail, -sheets | one message per poll with the 
return value of the method (`Events`, `FileList`, `ListMessagesResponse`, 
`ValueRange`) | the `inBody` parameter of the method, of its type; JSON text or 
a Map is not turned into a model object, and the description names the 
transformers and converters that build one | the model object; null for the 
methods that return nothing, such as the deletes (not for sheets) |
   | google-calendar-stream | an `Event` per event | | |
   | google-mail-stream | the first part of the mail that has data, as text; 
the whole mail as base64url text with raw=true | | |
   | google-sheets-stream | the `Spreadsheet`; a `ValueRange` per range; a List 
per row with splitResults | | |
   | azure-cosmosdb | a List of Maps per change-feed batch | a Map, a POJO or 
bytes for the item operations; JSON text fails, so unmarshal it first | the 
item as written; a Map for readItem; a List for readAllItems, queryItems and 
the lists of databases and containers; unchanged for the database and container 
operations |
   | azure-functions | | text, bytes or no body for invokeFunction | the 
response as text; Lists, Maps or a `Boolean` for the management operations |
   | azure-key-vault | | the value as text, bytes, a stream or a file for 
createSecret | `KeyVaultSecret` for createSecret; the value as text for 
getSecret; `SecretProperties`; null for deleteSecret |
   | azure-storage-datalake | a stream of the file (a `File` with fileDir) | 
text, bytes, a stream or a file for upload and appendToFile | Lists of 
`FileSystemItem` or `PathItem`; a stream for getFile; a `File` for 
downloadToFile; a `Boolean` for the others |
   
   The Google model classes count as POJOs, though they are also Maps of their 
JSON fields.
   
   **Checked at runtime.** Throwaway tests, not part of the PR, sent text, 
bytes, a stream, a file, a Map, a POJO and no body. No credentials were used. 
The setups:
   - **Google:** a fake HTTP transport behind the `clientFactory` of each 
component.
   - **cosmosdb:** the Cosmos DB emulator in Docker.
   - **datalake:** Azurite in Docker. It has no Data Lake API, so the dfs 
operations were not run.
   - **key-vault:** the real SecretClient against a fake REST server.
   - **functions:** a local HTTP server for invokeFunction, and a mock for the 
management operations.
   
   Not run:
   - the datalake dfs operations (upload, appendToFile, flushToFile, listPaths, 
createFile, deleteDirectory, uploadFromFile, openQueryInputStream);
   - the cosmosdb throughput replaces, for which the emulator has no offers;
   - some functions management operations. Their types come from the code, 
which builds the same Maps and Lists.
   
   The Google producers do not convert the body today: a body of another type 
than the parameter fails with "argument type mismatch". PR #28364 makes them 
convert it, and the description ("the inBody parameter, of its type") holds 
both ways.
   
   **Doc fixes**
   - **google-mail:** the update-message-labels and draft examples failed with 
"Missing properties". They need `userId=me`, and `inBody=modifyMessageRequest` 
for modify.
   - **azure-cosmosdb:**
     - The consumer example wrote the List of Maps of the consumer to a file, 
which needs text. It now marshals it to JSON first; the YAML validator of this 
PR's check reported it.
     - The createItem and replaceItem examples set a JSON String body, which 
fails. They now unmarshal it, in Java, XML and YAML.
     - The table says so too.
     - The second readItem row is readAllItems.
   
   **Bugs found, not fixed here.** The JIRAs, one per component, will follow.
   - **google-mail, google-sheets:** the methods that return a sub-resource 
fail with a ClassCastException ("cannot be cast to 
AbstractGoogleClientRequest"). google-mail `messages/attachments` and 
google-sheets `spreadsheets/sheets` were run.
   - **google-drive:**
     - `drive-files/export` always gives a null body, so there is no way to 
download the content of a file.
     - `FileConverterIT` uses `drive-files/insert`, which Drive v3 does not 
have.
   - **All four Google API components:** the method signatures say `content` 
where the parameter has another name (`modifyMessageRequest`, `values`, `file`, 
`batchUpdateSpreadsheetRequest`), so `inBody=content` fails with "No matching 
method".
   - **google-sheets:** the splitResult option is never read.
   - **azure-cosmosdb:**
     - A String body for the item operations, as in the examples of the page, 
fails with 400 "Document does not contain an id field".
     - A List body fails, though the code has unused helpers for a List of 
items.
     - A stream fails with a Jackson error, and a File is sent as its path.
   - **azure-functions:**
     - A stream body is sent as its toString, and a File as its path.
     - The default `Content-Type: application/json` is only added when the 
CamelAzureFunctionsHttpHeaders header is set.
     - A 500 response does not fail the exchange.
   - **azure-key-vault:**
     - deleteSecret sets the body to the final result of its poller, which is 
always null, so the `DeletedSecret` is lost.
     - A Map or a POJO is stored as its toString.
   
   **Local checks**
   - The changed modules build, with no change to the generated files after the 
build.
   - The catalog copies equal their modules.
   - camel-catalog, camel-yaml-dsl-validator and camel-jbang-core tests pass.
   - The Endpoint and Component DSLs regenerate with no change.
   
   🤖 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